Blockchain tech is just a solution to the Byzantine General's Problem. It's utility is that it allows people who don't trust each other to nonetheless reach consensus on the state of the network/ledger. But, it doesn't prohibit people who do trust each other from acting in a coordinated way (that is, colluding) to either protect the viability of the network itself or to attack it. When done to attack the network, such collusion is commonly called a "51% attack". When done to support it, it's commonly called a "fork".
For me, the question is which threatens the future viability of the blockchain most--reversing a series of transactions that resulted from a hacker exploiting an obvious coding error, thereby prohibiting a thief from stealing lots of coins or 2) insisting that "code is law" and that no transaction, not even those that result from obvious and extremely costly mistakes, should ever be reversed.
I argue that refusing to reverse via a fork, and thereby refusing to honor the original expectations of the DAO participants and developers, does the more damage to the network than forking would. If this particular exploit had been known with certainty to every DAO participant in advance, how many of them would have actually put money into the DAO? Easy answer: Few to none. And, if such hidden exploits are likely to exist in the future and participants have absolutely no recourse, how many are likely to invest in the future? Fewer. Much fewer.
Insisting that "code is law" and refusing to correct via soft or hard forks what we now know was obviously a coding error is essentially to insist that every single smart contract in the future will serve as a "trap for the unwary", with the "unwary" being essentially anyone who can't read code for themselves (and even a large portion of those who can). Note that taking this approach creates a perverse incentive for unethical smart contract developers to "build in" obfuscated backdoors that the developer himself/herself eventually intends to exploit.
Even if we assume naively that all developers will act in good faith, the fact is that virtually ALL software has SOME exploitable bugs, even audited software and even open source software. Smart contracts are ultimately just software, software that cannot be edited, and every one of them that is sufficiently complex will likely be buggy.
If the Ethereum community's position is going to be that there is never any recourse for buggy software because "code is law", even buggy code, then it's future growth and success relies upon expectations of the impossible: That programmers will suddenly begin to consistently write complex code that is bug free, or that the market will suddenly get much, much better at knowing in advance which software is buggy and which is not. Neither of these are likely absent major innovation.
In short, my contention is that market participants will respect and value that the Ethereum community independently chose to prevent a thief from undermining every single DAO participant's original expectations to the thief's great advantage. Reversing things via a fork will instill confidence in the system, leading to continued growth and investment. Failing to remedy the situation will result in the opposite: A permanent loss of confidence and decreased growth and investment.
Does this mean that we will have a hard or soft fork every time we discover a bug in a smart contract? Obviously that won't be possible once there are thousands or millions of smart contracts running. And, in some cases, it will be much less clear whether or not the software in question was in fact "buggy" or instead functioning as intended. Even so, just because the Ethereum community won't always be able to intervene to fix an error doesn't mean that it should not do so in this instance where the facts are clear, the error is obvious, and the amount at stake is large.
Disclosure: I do hold some ether, but I'm not a participant in the DAO.