ISTM that you're arguing from a perspective of intrinsic necessity. Your argument is that, anyone can cat a file into my utility, if they need that functionality.
Sure. However, for example, GNU sort doesn't work that way. Most utilities don't work that way. Most utilities accept a file as an source of input, and most of those don't act on the inode. That's the status quo.
sort is a bad example: to support sorting in-place, it has to know the file name. Pity the user who typed
sort < bigfile > bigfile
A general solution is something like:
$ sort "$name" | sponge "$name"
$ sort -o "$name" "$name"
This has bitten me occasionally, even though I know the workarounds (tempfiles or pipe-consumers like sponge(1)).
I'm wondering if there's any practical use for the behaviour, or if it's worth hacking a shell such that it produces a warning/interactive confirm prompt for it (or transparently buffers to DWIM maybe?)
It's pretty common to `set -o noclobber` in beginner dotfiles; doing deferred-open-if-exists is an interesting idea that would probably get a lot of resistance :-)
A third is "it uses multiple files (and the behavior can't be replicated by concatenating them)."
Picking one input to still be consumed from stdin can make sense, though. A special case of this is config files, which are almost never read from stdin (they usually have a default location or several).
Otherwise it still might be useful, but in general it's kind of unnecessary. It adds logic to your application that it doesn't need, which violates "do one thing, and one thing very well" (albeit only a very small violation).