“Flakes” are a big conglomerate of different features that all have different purposes (which in turn is one of the biggest issues with this, and why it’s still experimental like 7 years later). You seem to mostly be concerned with input pinning here. Input pinning is mainly useful if you use nix for software builds.
The feature does have the downsides you mention, but there’s a reason pretty much every code ecosystem has facilities for pinning dependencies these days. ABI compatibility is useful from a system deployment point of view, since being able to swap out versions of a library means nice things for security and disk space, but when developing software you don’t really care about that - here you only care that you have consistent behavior so that you can reason about what your software does; nix as a tool is all about ensuring this consistency.
This argument actually goes all the way back to the 80s/90s, funnily enough - back then it was about whether you should dynamically or statically link your dependencies. Nix, docker, flatpak & co. are the eventual answer to the dynamic linking folks winning that initial argument in the unix world, since that lead to issues for developers, especially as reliance on third party code dependencies has completely exploded (in the dos world the static linking folks won, and .exe files are still universally bloated to this day!).
So, input pinning is not very useful from a NixOS user’s perspective, and can indeed be argued to be a downside, but from a developer-using-nix perspective input pinning is absolutely essential. Without it nix doesn’t solve the “builds on my machine” problem it’s supposed to solve at all.
The feature isn’t very well thought-out, unfortunately, precisely because it lacks facilities for advertising ABI compatibility. You could easily pin inputs intelligently, ensuring that your input tree respects ABI compatibility - like e.g. rust’s cargo does. Detsys have a proprietary solution to this problem, which, well, let’s just say their championing of this flawed design, and later insistence on marketing flakes as “done” has left a bad taste in the community’s mouth.
Flakes also aren’t the only (nor the first) implementation of this in nix land. I’d argue niv is much less intrusive. Nix should have built-in functionality for input pinning, it’s a shame that the current design is lacking and that it comes with all this other baggage.
So bottom line, why pin your inputs with flakes? Because that’s very useful for software development. The feature is also currently flawed and really needs work.