I totally agree with the general idea, and this is generally how I build backends these days. If there are multiple clients, it's usually even ok for each to have a backend which talks to the "master" backend.
But I will never get on board with sending things like content or UI related stuff from the backend. I've seen too many times, engineers think "all our forms are the same, let's just have the backend send a list of input field names and types like 'address'". It's almost always a bad abstraction, causes pain on the frontend, and restricts the creativity of engineers and designers.
The article doesn't disagree with your second paragraph. It encourages to treat each "page" as a unique snowflake, including forms in it. I should probably do a better job to discourage consistency and standardization of these json structures. This is addressed in another one of my comments if you search for "my bad".
But I will never get on board with sending things like content or UI related stuff from the backend. I've seen too many times, engineers think "all our forms are the same, let's just have the backend send a list of input field names and types like 'address'". It's almost always a bad abstraction, causes pain on the frontend, and restricts the creativity of engineers and designers.