Hi! I'm the author. Great question.

"I probably would have returned a blob of data from the servers" That would certainly work, but adding new functionality to the rooms would require changes on the controllers (implementing the new JSON API) and on the client (calling, handling, and rendering the new feature). I wanted to minimize development time for myself now and make it possible to add new features using only C++ later.

Having the server declare the supported actions (not all rooms support the same features) and how to invoke them accomplished that. This independent evolution was a big reason why I leaned into HATEOAS.

"wouldn't have figured that doing handlebars style html templating is a good use of resources" I didn't do a size comparison between the HTML fragment and a JSON response. Next time I'm at the house I'll come up with some measurements and add it to the article - I think it's interesting. That said, the performance was more than enough for the business and each of the controllers still had plenty or RAM and Flash Memory available, I didn't need to optimize this area. If I was going to, I'd want to avoid going through the buffer so many times.

That said, the simplicity and robustness of the HATEOAS approach were the main goals. I wouldn't use it for something like high-frequency trading where every byte matters.