Such a display-only narrowing might be a good alternative for many uses
of narrowing, but narrowing is also used quite commonly (either by the
end-user or in ELisp code) in order to restrict the effect of an
operation (like search&replace) to a particular region.
Certain operations could look up the "soft narrowing" bounds and act
accordingly, if it's implemented in the core and appropriately documented.
Could be, but unless we go through the whole C code looking for checks
of BEGV/ZV and updating the code to also check the "soft bounds" this
won't work reliably enough to replace existing uses of narrowing.
To my understanding, there are more commands and facilities that want to
ignore user-level narrowing, rather than the ones that want to obey it. Also
a lot of "undecided" ones, waiting for someone to report that they should,
in fact, ignore narrowing.
But for backward compatibility reasons, we can't break the cases that
need the bounds to be hard, even if it could fix some cases.