They'd probably call the issue you see a "craft" issue. Some PM is likely raising it. What happens is that leaders in big companies want perspectives based on data. You can go in with issues like yours but if you don't have clear data that shows significant numbers of users leaving, or users piling in, then you might as well not show up. People care about craft primarily will really struggle in these large organizations. That's not a good thing but how it is.
In large organizations, you'll see a lot of A/B testing or experimentation. Some of the worst decisions from a craft perspective are ones where they only look for "did this cause some kind of negative impact on numbers?" situation. If your feature is neutral (on abandons, uninstalls, or whatever negative outcome), then it can get shipped which overrides any qualitative question around "should we ship this in this state?". Doesn't matter too much according to these folks because it's not making things worse (in terms of numbers.)
There is probably more to explore in modern "product management" that's at the root of many of these problems. HN tends to focus on engineering but within large companies there is now a bifurcation and development of a field that forgets lots of PM was already invented.
How do the metrics you speak of capture these subtle, delayed effects?
I can guarantee you that the class of problem you describe has been discussed at the individual contributor level, so is known to some extent. Getting it from recognition to action is the problem. It is a huge lift to get some of these small things through the gauntlet to execution. Meanwhile, as you say, competitors with taste and attention to detail are building a better product.
This is very much a problem of large organizations. Those same PMs at a small company. If Google Maps was an independent company, the impediments would be fewer and priorities more aligned with building the best Google Maps.