It's designed around the idea that the user chooses the width of their browser and the page becomes as long as necessary to fit all that content by scrolling, just like a word document. Centering, especially vertical centering, is kind of hard to define in that context.
When you start adding features to give web developers pixel-perfect control of the viewport then you impede other features like allowing the user to choose their own font sizes while still having everything render in a sensible way.
Apples AutoLayout already does this — and in a much more elegant way. I’ve been making MacCatalyst apps recently and have been searching hide and wide for a 1:1 UIKit/AutoLayout <> Web front end (aka a rats nest of js, css and html).
I would argue AutoLayout has a way easier job: There are less backward-compatibility concerns, everyone is using the same GUI-based editor and there are many less device configurations to account for. It is also arguably less flexible than the Web in terms of the range of UIs that you could create.
1. A page is tet + images. Complex layouts are very late invention for HTML
2. The whole layout can be done in a single pass.
This was crucial for the 90-s era browsers because you wanted to be fast on rather underpowered machines. I think double-pass was permitted/mentioned in standards only around 2000/2001 with relation to tables (I forget what it was exactly). Centering an element vertically may require several passes (do the rest of the layout, layout the component, layout the component centrally, possibly reflow the rest of the document, etc.), and it was a big no-no
When you start adding features to give web developers pixel-perfect control of the viewport then you impede other features like allowing the user to choose their own font sizes while still having everything render in a sensible way.