Fork would be much less of a problem than building block chain with blocks that inflate the coin supply without anyone realizing.

Existence of an unexpected fork is a serious alarm signal that the entire system can act upon, e.g by stopping any economic activity until the situation clears up.

But what are you going to do upon realizing that e.g. for the past week someone has been mining blocks that increased the amount of coins in his wallet by 10% of the extra BTC supply?

Obviously, as soon as you realize the screw up you make sure everyone upgrades the software.
But how are you going to handle the existing damage?
Well, I think in such case you basically end up with only two choices:

1) You let the guy keep the money he created out of a thin air, most of which he probably already spent anyway - all the expense of all the other bitcoin holders.

2) You invalidate all the blocks (transactions) from the past week - pushing the damage on the ones that accepted any payments during that time.

You can also think of invalidating the coins that were "added illegally", kind of like ethereum did with DAO hack (although they invalidated a reallocation of coins, not creation of new ones).
But assuming that the guy who came out with the exploit wasn't an idiot, they are long spent already and mixed with a "legal" coins, so that's not really an option.

My point is: whenever such a catastrophic event happens we want to know about it as soon as possible, to try preventing the damage.
That is why having only one software implementation is a very bad idea.