> I wanted to create an architecture that minimized future work on both the admin app and the controller network layer. That way, the business could lean on its in-house development experience to make changes after the project.

From your perspective as a UI developer, you would need to update all clients (in the building) if something on the server changes, e.g. if a new button or game state is added. HATEOAS is a good architectural choice if you want to minimise the likelihood of having to change the client implementation.

I use HATEOAS as much as possible in my daily work. It is a good way to think about state, state transitions and what capabilities a client must have. That's the actual part of the author's motivation. It provides the "in-house development" with paradigms how to make changes.