They are not directly in control of the objects rendered by the browser. They have to go through HTML encoding first and then the browser has to render the HTML.
The goal of these frameworks is to make things simple and webpages don't tend to need a lot of logic.
Considering point 1. Pages consist of components and components can have sub components. The alternative to global state requires events that get passed back "up the tree" from sub components to the page and then back down again to other sub components.
If you are rending a window in directx at 60fps and each component reads its values from memory this is pretty simple. Hook up your events and you are go. If you have to calculate all the changes, render virtual HTML, check of differences with the last frame, alter the HTML, write the altered HTML to the DOM, wait for the browser to render the new HTML you may have performance issues.
Also its hard to write the framework. If you have global state you can change it and redraw once from the top down.
Considering point 2, global state is easy to understand and program. I don't need events or call backs or mediators, I have one, one way, draw loop. Do I need more for 90% of webpages?
But yes, I agree its not good practice and for complex web applications it makes things awkward and highly coupled. However. Another rule of programming is don't try and fight the framework. Maybe vue is not suitable for complex interfaces and you should go with a canvas and pure js, or web asm