HTML and CSS are the way they are because they, together, are markup for
documents--and documents on the web are of indefinite shape. You can resize your browser window, or change your text-zoom, or insert/remove content in the DOM, and things have to
reflow. Most importantly, this means that boxes containing reflowed text will get
longer or
shorter, and then push other boxes on the page up or down.
Because of this, it really makes no sense, in the context of an HTML document, to center something vertically--it'd just end up at some arbitrary position on top of some paragraph in the middle of the page's content, found after N/2 screens of scrolling. This is what separates an HTML document from, say, a PDF: PDF pages don't reflow, each one has a fixed height, so there is such thing as the "center" of a page on a PDF.
If the web were like PDFs, sure, it'd be easy to render it all using WebGL. But try imagining, now, writing an interactive text-layout-and-reflow engine in Javascript, to render web documents onto a WebGL canvas. How would you specify the constraints for that engine to follow? Some sort of declarative markup language based on a box model with paddings, borders, and margins, perhaps?
---
Now, on the other hand, web applications tend not to care so much about the shape of any "document"--what they're interested in is the shape of the viewport. That has completely different semantics, and can be done easily in WebGL ("viewport" being a jargon term in GL.)
But... web applications tend to embed, and rely upon, the reflow semantics of web documents surprisingly often. As soon as you want to include any controls with user-contributed content, you need that rich-text layout engine, and you can't just pre-render it all to a canvas to bring it in, since users will want to copy and paste text from it...