It's not really clear what this even means. HTML5 and CSS3 aren't new versions of HTML and CSS that obsolete the prior stuff; they are extensions to what already existed.
So, for example, as far as I know, every web browser uses the HTML5 parsing algorithm for parsing HTML. This algorithm is very complicated, because it describes what parse tree to produce for any possible document. There's not, like, a separate HTML4 parsing algorithm; the HTML5 parsing algorithm replicates a lot of the complexities of pre-HTML5 parsing, but standardized.
Similarly, in CSS 2 the biggest complexities are things like floats, inline layout, margin collapsing, and stacking contexts. (My PhD was most of a standards-compliant CSS 2.1 layout engine.) There's not a CSS inline layout algorithm (the thing that puts words into lines) other than the CSS 2 one, though CSS 3 does add a lot more features.
In other words: the browser doesn't have a separate code path to handle old content. Instead, CSS 3 contains layout algorithms that extend CSS 2 but they don't replace them.[1] Similarly HTML 5. There are obsolete features you could probably dump (obsolete image formats, obsolete codecs) or rarely-used features (eval, document.write) or edge cases that probably don't matter that much (margin collapsing) or features where maybe your user base doesn't need it (writing direction? floats?) but this is really not so different from what the article talks about: a WebView/Electron replacement, where you commit to supporting a known universe of pages instead of the whole web.
[1] Granted some features like floats have become a lot less necessary, since a lot of their use cases can now be replaced by flex-box.
It's a semi-noob illusion that focusing only on modern standards and practices would surely result in a leaner implementation. This goes all the way back to the big push for web standards in 1998—e.g. you can find Slashdot Q&As from the early 2000s where people bring up the idea of how much smaller the browser could be without quirks mode and IE compatibility and then get corrected about how much of the code base this stuff actually takes up.
It's a lot easier to implement the HTML5 parsing algorithm from the spec than trying to reverse engineer it yourself. That's a completely separate matter from the confused belief that "ignor[ing] everything that's not modern HTML5 and CSS3" would somehow "cut down on the scope significantly".
It's not a huge benefit because they are simpler; they are usually
equivalent to the old standard. The benefit comes from newer standards
being a lot more precise.
e.g. HTML4 did not specify what to do with invalid markup, which makes
writing a conformant parser easier. In practice, many websites weren't
valid HTML4, so you had to reverse engineer whatever the other parsers
did with invalid markup.
HTML5 doesn't really have a formal grammar, it's specified as an
imperative tokenizer and parser. It actually takes somewhat longer to
implement than HTML4, but it doesn't suffer from compatibility issues.
OTOH there are new problems with the "modern" standards that old ones
did not have:
* It's unversioned, updated pretty much daily; insert walking on water
quote[0].
Random example: I added support for the (ancient) document.write API
to my browser a few months ago. Recently I looked at the standard
again, and it turns out my implementation is outdated, because there's
a new type of object in the standard that must be special cased. Many
similar cases; this particular one I don't mind, but it shows how hard
it is to just stay fully compliant.
* It's gigantic and bloated, full of things nobody ever uses. If
something gets into the standard, it typically won't ever get removed,
and WHATWG has operated under this policy for more than a decade. So
implementing it from start to end takes way too long, and the best
strategy to get something useful is to "just" implement features that
websites you use will need.
* Above is the WHATWG model, which applies for HTML and DOM, but not
CSS. The W3C model (used in CSS) has versioning, but they broke it in
a different way: there is no comprehensive "CSS 3 standard", just a
bunch of modules haphazardly building on top of each other and
CSS 2. Plus it's much less precise than the HTML standard, with basic
parts left entirely unspecified for decades. See the table module[1],
or things like this[2].
[0]: "Walking on water and developing software from a specification are
easy if both are frozen." - Edward V Berard
[2]: https://github.com/w3c/csswg-drafts/issues/2452 - "resolved" by an
unclear IRC log(?), but never specified to my knowledge. It's not
an irrelevant edge case either, Wikipedia breaks if you get it wrong.
So, for example, as far as I know, every web browser uses the HTML5 parsing algorithm for parsing HTML. This algorithm is very complicated, because it describes what parse tree to produce for any possible document. There's not, like, a separate HTML4 parsing algorithm; the HTML5 parsing algorithm replicates a lot of the complexities of pre-HTML5 parsing, but standardized.
Similarly, in CSS 2 the biggest complexities are things like floats, inline layout, margin collapsing, and stacking contexts. (My PhD was most of a standards-compliant CSS 2.1 layout engine.) There's not a CSS inline layout algorithm (the thing that puts words into lines) other than the CSS 2 one, though CSS 3 does add a lot more features.
In other words: the browser doesn't have a separate code path to handle old content. Instead, CSS 3 contains layout algorithms that extend CSS 2 but they don't replace them.[1] Similarly HTML 5. There are obsolete features you could probably dump (obsolete image formats, obsolete codecs) or rarely-used features (eval, document.write) or edge cases that probably don't matter that much (margin collapsing) or features where maybe your user base doesn't need it (writing direction? floats?) but this is really not so different from what the article talks about: a WebView/Electron replacement, where you commit to supporting a known universe of pages instead of the whole web.
[1] Granted some features like floats have become a lot less necessary, since a lot of their use cases can now be replaced by flex-box.