Having developed both HATEOAS and non-HATEOAS systems. The HATEOAS systems were categorically less brittle, easier to change, and had faster turn around times. The immediate benefits of resources and verbs in greenfield development are easy to spot, but ongoing system evolution is where HATEOAS's value prop shines.
It's a common misconception that complexity is a zero-sum game.
There are gains to be made from certain design decisions and HATEOAS in my experience with multiple front end teams and multiple back end teams working in HATEOAS-land is that the HATEOAS systems were able to address ongoing systems evolution in ways that when complexity did come up, it was easier to address and manage.
I'm not here to proposition it as a silver bullet, or have quantitative data to substantiate it, but in my experience the ease of ongoing system architectural evolution in both client and server realms made up for the difference in tension between the two camps.
One example of a tension in HATEOAS is the complaint from clients that they can't hardcode links like they did before. One of the points, obviously, of HATEOAS is the ability to represent state using hypermedia[links]. One terrible thing the backend could do is make clients traverse multiple resources to get a url to perform an action elsewhere[1].
Rather than saying "tough luck, deal with it," communication workflows and architecture was adjusted so that for most workflows, the required urls were made available as a natural part of accessing resources needed to accomplish the workflow.
Does this require some work on the client to extract the link and use it for the next step in the workflow? yes. Do the other benefits make up for it? It did in my org. It might in yours. Part of being a good architect is making that decision correctly more often than not.
1. I'm being a bit loose with terminology, but I hope it helps rather than detracts from understanding.