I agree with you that not everything has to be done a certain way. Programs don't have to be written in C or functional programming for it to work well. But there are places where those excel in terms of performance and/or reducing complexity.
I am also not arguing that incompatible APIs will disappear with blockchain usage. But things like an EVM can be used as a template to build underlying blockchains to provide a common datastore and execution layer for multiple systems to work together. It is harder to achieve with traditional SQL databases, which shouldn't be publicly accessible.
Also an advantage I thought of is it would be harder in this case for corruption to take place in the PCR testing regime since all transactions are immutable, and transparency ensures that the public would be able to check against those if they so wish. A closed system would allow the government or participating platforms to manipulate data records for their benefit, with less chance of scrutiny.
I agree with your points about the vulnerability of smart contracts and private keys. These are challenges that I hope will continue to be addressed as we try to figure out how to make blockchains accessible for mass usage. I think that smart contracts auditing is still far from mature, but the immutable nature of contracts would allow audited contracts to remain secure, as opposed to some code running on some company's server.
In the end as with everything in life, there are trade offs. It's about picking the right tool for the right job, and to continue experimenting with potential improvements that new technologies can bring and to reduce their externalities.