You can add new functionality by adding new endpoints without using HATEOAS too. The only difference is that it's documented out of band, which incidentally, is primarily a discovery-related concern.
Exactly. It's not just the existence of the endpoints, though. It's also having developed the client from the first release to be HATEOAS-aware which makes the whole thing interesting. If you do that you'll have conventions in the client code which, even if you're not doing automated discovery, will make it easier to add functionality to a new release.
Write most client code in a generic way so that it's easy to add new actions? Sure.
Write the client to use new actions without needing an update? Impossible.
Output the list of available actions using <link rel="..."> rather than some domain-specific tag? What do I ever gain from this other than bloating my API and making it harder to read?
In some cases, client code could be written so that new actions can be discovered and utilised without any changes to the client code. There have been many cases when I've written code that renders things, and I've reused that code to render multiple different things. Eg I might have a page that lists blog posts, and another page that lists comments on a blog post. Some of those things can be deleted, some of them can't, but the code to delete is there for both of them, it's just that on the ones that can't, the delete button is hidden. Using HATEOUS, if the server did start supporting deleting something, that could automatically detect that, and automatically support that new feature that the server now supports.
