With the advantage that you have attributes (background-size, etc) to handle image resizing and alignment without having to faff around with imgs, divs to contain said imgs and a bunch of CSS rules for each for hours?
AND the advantage that you can have one single file for "media" definitions that allows you to swap images around when needed (just change the url()) without having touch 347 HTML files just to set the image src?
Or maybe I am missing the point.
The cascading part of CSS means the a later rule could override an earlier one, so to determine which image variant to download when looking at the css the browser needs to parse the html, parse the css, link the two. A css rule may end up not even applying to any elements on the page if a particular selector has no matches. Only after all this can it begin downloading the actual images.
Using srcset/sizes the browser parses the html and can begin downloading the correct image variants immediately, before it parses css.
With prefetching enabled this means your browser could parse the html and cache all the image variants on the page that you'll need when hovering over a link to another page. So when you actually click on it everything is loaded from cache and super fast.
It's up the browser to manage situations of lower network speed, pixel density, etc. and to determine when and how much preloading to do. Using srcset/sizes just gives the browser the option to optimize as much as needed.
I did not consider the overhead of the browser parsing the CSS file and then figuring out which rules are applied where and depending on what rules are being applied, figuring out what else needs to be downloaded, etc.
But is that overhead really that significant? Or will the responsive images approach merely shave off a few % off the page load time?
And something like srcSet will possibly allow the useragent to become "smarter" in the future. Perhaps halving image size when low on battery, or when on a limited mobile plan.
This isn't you choosing which image to serve who as a developer, it's serving up a bunch of options and letting the useragent choose which it knows is best for the user at that time.
If you're on a slow connection, it can make a page load like it was loading from cache. Which can be quite significant compared to the css approach.
The question of whether the time spent implementing the feature is worth the benefits for a particular project / audience will vary on your use case.
What you're describing can mean loading something large and resizing responsively -- which can result in enlarged photos or wasted bytes to load an image of a size you don't need.
This is an interesting approach for people who don't mind cluttering their HTML, but want to scale media appropriately.
So you could have media queries for small size, medium size and large size with urls pointing to different images, and only the appropriate image will be downloaded and applied, thus achieving the same effect.