Wow, lack of CORS in the REST API really limits its utility!
Yup. It really open some possibilities. "Wasteful" is a good term.
I have long wanted to include a static .html page in a branding kit, with some JS to
directly invoke RouterOS from the page – no backend required, no container, and everything be
local to CPE. But the lack of even a CORS "same-origin" mean some backend and/or CORS reverse proxy is required.
I did put in a formal feature request (SUP-99112) a while back, and got a "we will see what can be done here" a while back – so semi-positive news. Specifically I purposed have a checkbox to enable in /ip/services with along with list FQDNs for the "allowed origins" returned by REST API to maintain CORS's schemes*. On client-side, still have to the CORS dance (e.g. includeCredentials: true etc in fetch()/XMLRequest/etc) - but those are solvable. The lack of CORS headers being returned from REST server is not.
* there are many CORS rules on client side, so cors-allowed-origin header cannot be "*" when using credentials & RouterOS requires creds (e.g. basic auth)...so REST API have to deal with the origins somehow