The engineer who wrote the contract appears to have made a critical logical error.
That does bring me to your conclusion, though. I've paid less attention to the marketing and promises and have assessed the technology as-is (within the confines of my knowledge) -- as such I see what's possible instead of seeing it as a product that under-delivers.
I wonder if a lot of people (especially on HN) would view it differently if it weren't for such bold claims on the developers' part. I mean, I think you're probably right in it being naive in its guarantee of predictability. I think any actors on the platform should assume its supposedly perfectly predictable behaviour is not quite so when they take to designing software or a contract. But that's part of what I meant when I've said it comes down to engineering practice -- when it comes to critical systems assumptions just shouldn't be made in young technology no matter what anybody tries to sell you.
To use your analogy - I'd view the bridge design engineer as having guaranteed that the design process could not possibly result in construction of a bridge that fails. That seems closer to what Ethereum would have us believe.
A bridge design domain expert presumably understands: - that design process uses strut calculations (and therefore includes measures to guarantee those calculations can never be wrong); - that bridges may be built from steel (and therefore includes inspection routines that guarantee faulty steel can never be used); - that the environment acts on bridges through corrosion and earthquakes (and therefore includes routines that absolutely always preclude failures arising from the bridge's environment); - etc., etc., etc.
Maybe it's just my ignorance or misunderstanding of this domain, but I see Ethereum as naive in its guarantee of perfectly predictable behavior.
A guaranteed flawless protocol that fails (for whatever reason) when implemented in reality, isn't.