I stumbled upon this post recently and I love it. It summarises very nicely my own feelings.
I went down the path of exploring HATEOS and Collection+JSON and it all started to feel like enterprise architecture style over complication for very little benefit.
I believe it's actually the other way around, where HATEOAS is the least "enterprisy" of the options. When I think of enterprise or over-complication, I think of a system where logic is so deeply embedded in the server and client that if the client or server changes in any way, everything breaks. REST was designed to better handle changes between a client and server. For instance, if you built your API to use something like Collection+JSON, then it could be instantly read and understood by any Collection+JSON client (much like in the way the HAL browser works [1]). You could change things, move things, even redo URLs, and the client will still work.
If, on the other hand, you don't conform and use HATEOAS, you have to go look at the documentation on how to build the URL to make a call to the API. Your client can never explore an API, but must be built to make certain calls to certain URLs that are built a certain way.
True REST with HATEOAS was what HTTP 1.1 was built around. It may take some extra work to implement, but it was designed to make communication over the web simpler (and it's worth the trouble). Unfortunately, this article is not really endorsing what REST is, but rather a very common RPC that has been popularized by Rails and labeled as REST.
I went down the path of exploring HATEOS and Collection+JSON and it all started to feel like enterprise architecture style over complication for very little benefit.