We have a single-page app with lots of dynamically created elements. We discovered a case where Chrome kept input focus on an element that was deleted and recreated, while Firefox didn't, resulting in different behavior if the user pressed Enter next after clicking on that element. (I don't know which of those is the bug, if either. We wanted the Firefox behavior so I hacked in a .blur() in the event handler for Chrome.)
How do you feature detect a crash bug? Or a leak? If you run the code that crashes, you've crashed the page and can't then run alternative code.
But on the other hand, there are certainly some cases where you want to know actual browser version to work around the critical bugs: e.g., Safari 13 (I think?) had broken their implementation of WebSocket compression for about a year: the byte stream becomes garbled after about 64 KiB of data transmitted, and the WebSocket connection breaks down. How do you work around that without UA string?
And on the third hand, we may have proper APIs for feature detection nowadays but — how many webdevs actually have heard of them? And willing to update their legacy codebases? I personally haven't although I'm not a webdev by any stretch. And when one tries to google how to e.g. support some feature in different browsers, there are lots of older pages/resources/answers telling how to do it with contents of the UA header.
"there exists a use case that wouldn't be possible to implement without user agents" is not an argument. it's not philosophically valid. its dead obvious that you do not consider the whole picture if you make this argument. why does that 0.1% use case matter? especially given that it's not officially supported. especially given that for the last 10 years, the likes of google have shoved everything _straight_ into the web specs when they started considering it an official supported use case? if you are doing something that's not an official supported use case, why do we need to have hacks to support it? obviously the least ecologically harmful solution is for your use case to not be supported. of course we are talking web here, where scope creep is infinite and the protocols do nothing well instead of one thing well.
this is the very problem with the web, that "it doesnt have a concrete use case maaaaan", "ill just add and take what i want as i go", "the web is just the web maaaan you need to think on my wavelength to get it". these people embedded in web actually unironically just make shit up as they go along. they literally operate on an oscillating wave where today feature set 1 is good, tomorrow feature set 2 is good, and the day after, (what is essentially) feature set 1 is good. arguing to have a user agent string is the same idea. this is in strict contrast to a well designed product that actually solves a specific problem, like Standard ML, or a good SQL implementation (disregarding the specification conundrum) or JSON or VGA or TCP.