HATEOAS is a pain in the ass to implement, people know what it means, they just don't bother implementing it. It's often not a necessary feature for an API. HATEOAS is even more painful when using JSON, a format that doesn't really support metadatas ( a link is meta compared to a ressource ) and very little clients are built with HATEOAS in mind.
The REST paper has good ideas, and people are picking and choosing what they want. There is no REST specification that makes HATEOAS mandatory. Maybe Roy Fielding should have written one on top of HTTP to make it clear what it is about instead of writing an dissertation.
How do you represent a link semantically? 100 businesses will have 100 different answers. That's why, by the way, HTML was so ingenious. HTML tags ARE semantic. If Roy came with a core set of tags describing things then people would know how to write basic HATEOAS APIs.
So don't blame the people, blame the absence of a clear specification(and no, the REST paper is not a spec, a spec is normative).
All this shouldn't matter as long as every IS documented. HATEOAS can't replace a good documentation. Today, for most developers REST is about urls, verbs and caching + a few other headers, nothing more.
Many do know. But they just choose one step lower lever on Richardson maturity model as more pragmatic. Yes, according to Fielding that level cannot be called RESTfull, oh well…
Also, verbs are not RESTful. Verbs imply an RPC interface.
RPC (verb):
REST (noun):