Doing this makes a lot of sense for any web setup where you already have something you're calling an "asset pipeline", but can seem pretty nuts where you're writing simple no-JS HTML.
and you only need to bother with this on images it might matter (e.g. key large multi MB photos in a blog post or something not all of the 20x20 logo icons that would be less than 2kb even if uncompressed).
The HTML isn't bad, sure, but the process of generating appropriately scaled and formatted copies of images can be if you don't have other build steps that require similar automation.
Appropriately scaled is always a problem at which point you hit save/export twice and you've done everything you need.
Unless rescaling an image itself is already too much work, in which case this has nothing to do with image formats or plain HTML sites in the first place.
nothing about web for the last decade has been about no-JS HTML
its an option but doesn't leave you anything to contribute. the web is fragmented most of the toolchain is for simplifying deployment into that fragmented place without caring that it is fragmented. so not really nuts when everything already takes care of it for you. you can stick with no-JS HTML cached on an edge node just as well, or not cached if you expect low traffic, its whatever.
"everything already takes care of it for you" is fine if you're willing to have a dependency on "everything". It's "whatever" relative to how much the people who load your page care about bandwidth.