Browsers accepting tag soup is just a manifestation of the Robustness Principle [1]:
"Be conservative in what you send, be liberal in what you accept"
(Also, I'll point out that HTML allows the parser to abort at any parse error it defines, the first time it hits that parse error. So you can implement a relatively strict HTML parser that rejects content and have it comply with the spec.)
I wouldn't expect huge perf increases, but there are a few minor non-local effects such as self-closing tags that imply more branches than strictly necessary. It's not going to add up to much of anything, that's for sure. A simpler spec might, however, leave more complexity-budget for clever optimizations, but that's pretty speculative. The kind of thing I'm thinking about here is that when the language is fairly restrictive, you can consider using SIMD operations to match content cleverly; e.g. you might find the closing quote of an attribute four-chars at a time. Those kind of tricks require interplay decoding and parsing and are typically way to complicated in all but the simplest of cases.
In any case, this is drifting off topic: perf is not a primary reason to aim for simplicity, it's just a possible windfall.
DTD validation? As far as I'm aware, it would only be keeping it at a spec level—no implementation aside from validators ever implemented it. There's nothing stopping a browser from noting any validation error, though (and note they wouldn't just happen at parse time—they could happen following any DOM modification).
You say the HTML tag has no meaning, but it has the advantage of being explicit instead of implicit, as well as universal.
There are situations where implicit is better, because the explicit way feels like a big waste of time and demotivates developers.
There is also a lot of value in conventions, as all the efforts around coding standard and linting tools show. It forces different people to work more similarly, using an established way to do things instead of their own quirks, facilitating collaboration and sometimes educating them about the features and caveats of whatever they're using.
I've never been annoyed writing <html>, <head>, which happens a handful of times in the lifetime of a project that I'll spend thousand of hours on.
Again, I don't think any of this is relevant here, as those optional tags would be cleaned up at build or rendering time, and reinserted by the browser / parser. This seems like an awful lot of computation to save a few bytes though, but maybe processing power is that cheap nowadays.