Wierda does not write a neutral reference: he writes a manual with a position, teaching the language while pointing out where it is ambiguous, where it misleads, and where it pays to depart from the comfortable reading. That honesty is what distinguishes it from the official documentation.
What I took from it
The demand that every relationship mean exactly one thing. In most maps I have been shown, an arrow might mean that one system calls another, that it sends it a file overnight, that it depends on it, or that somebody installed them together. A map where the arrow means four things cannot be used to decide anything. Since then, before drawing, I define what a box and an arrow mean, and I write that on the map itself.
The second idea is what gives the work its commercial value: model the business process and the application service separately, then connect them. With that you can answer the question management actually asks, which is not how many systems there are but what stops working if this one goes down and who cannot do their job. An application inventory does not answer that; a map with that connection does. And it has a useful side effect: when nobody can name the process an application supports, that application is usually surplus.
The third is consistency of granularity. Mixing a whole system and a single form in one picture leaves the reader unsure what they are looking at.
What I left out
The notation, for client work. ArchiMate is a language between architects and it puts a room of managers to sleep in two minutes; the rigour stays, the drawing gets translated. I also left the book as continuous reading: it is hundreds of reference pages, written to be consulted, and anyone attempting it front to back will give up around the first third.