It's possible to save gas by pulling in libraries' code into the contracts via the "internal" keyword . This way JUMP will be used instead of DELEGATECALL.
Peer reviewed libraries will definitely help to make the platform more secure. However, the engineers decide whether to use libraries or not. What's needed is more discipline and willingness to raise the overall quality level of smart contracts and DApp development.
Writing software that handles money is different from some random web app, where bugs can be quickly fixed. We see some ICOs using OpenZeppelin  for their contracts, using practices like continuous integration and measurement of code coverage. However, we need much more quality-oriented practices to become widespread like mutation testing. In the current environment, developers are often more motivated to participate in bug bounties or exploit already deployed code, rather than contribute to the ecosystem/tooling.
the reason for all these hacks is not stupidity or laziness of the developers. the EVM execution model just makes it very easy to write vulnerable code.
If the creator of Solidity, Gavin Wood, cannot write a
secure multisig wallet in Solidity, pretty much confirms
Ethereum is hacker paradise.
Gavin Wood DID NOT write the change that caused that bug, he was not the assigned reviewer either. https://github.com/paritytech/parity/pull/3773
It's not true to say that something is secure just because it hasn't been broken yet.
I agree with your call for balance, but it's unnecessary to jump to the opposite extreme.
i don't think it's impossible to write secure smart contracts but it takes quite a bit of care even for simple stuff.
there are many issues that arise because your functions might be called by an adversary who has set up the stack in an evil way.
Would you sign a contract that references a contract that can be changed at anytime without your agreement?
Also, keep in mind that financial contracts are not subject to hacks, unlike smart contracts, as we have seen several times. One of the goals of upgradeability is the possibility to roll out security patches as needed.
the difference is, if someone does something really abusive with one of these clauses, a judge will throw it out.
zOS takes this one step further, including not only libraries for SC development, but also aiming at defining interoperability standards, mechanics and economics for having independent contracts interact between them as independent actors (or processes, if you will) on a shared computing space that is the blockchain.
I think the key here in terms of semantics is that zOS is not just an Operating System, but rather an Operating System for the blockchain. And when we go there, we don't have many definitions available, but are rather waiting to be made.