The problem pointed out in this article isn't that it is impossible to write correct contracts. The problem is that it means that it is
superhumanly difficult to write correct contracts, using the current feature set and infrastructure. This is especially true in what is theoretically an actively hostile environment, which the DAO hack proves is also
actually an actively hostile environment.
It is theoretically possible to call out to another contract that has the ability to make further calls safely... but how can you be sure you've done it safely?
This isn't a unique problem. It arises in imperative-based programming all the time. But what in Javascript may be a bit of a coding error that means the next page of search results didn't load this time, in Solidity it means you may lose your shirt.
Also, I'd suggest that after-the-fact "static analysis" tools don't help. It's basically the same situation that real-world computer security is in, and right now, that world is massively advantage attacker, with generally far less direct incentive to attack than a blockchain functioning directly as money does. If the static analysis tool is open enough for "everyone" to use, the attackers get to use it too, and they can use it on all contracts at once because they're all open, and they have all the motivation to do so before the proper contract owners have time to fix their contracts. Every time the static analysis tools release a new check, it's an advantage-attacker race between exploiting the new check and fixing the contracts. The attackers are going to win big, repeatedly.
A Turing-complete blockchain needs to come out of the gate nearly 100% correct on this front, just as it needs to come out of the gate nearly 100% correct on the encryption security.