No, the article argues for a very complex tag, which still doesn't provide enough information (like data rate specifications) for a browser to make an educated guess for the available optimum. Note that these are totally diferrent concerns: defining the viewport (which belongs to the tag) and its endpoint, on the one hand, and technical specificity of available media on the other hand.

(Putting all information in the tag is a bit, as if we were to define in an image tag, whether the image was encoded progressive or not, what size the color pallet is, etc. However, we can't put this in a video header, as this comes too late, as we decided for a specific source already. But there's the 300 "Multiple Choices" response, maybe, we may build on this.)

Edit: What really matters to an editor of an embedding document is selecting an endpoint (like "example.com/videos/cute-cat1") and defining its visual properties, probably responsively and by means of CSS. An editor is not concerned with quality levels and bit rates vs bandwidth, actual display size, etc. The editor even isn't in any position to make a suitable decision for every situation beforehand. Available options should be advertised by the endpoint and the browser should select adaptively the optimum to fill the viewport on its own behalf (and not by delegating this to the providing host by means of a handshake, which makes things not only unnecessarily complex, but also leaks information).