I could not find anything about google or other browser vendors in the article.
My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and executed at any moment, swapping implementation on the fly. And due to skills needed to actually read and understand executed scripts), so you can only believe and trust. At which point usual TLS is surely enough.
But we are talking about protecting data at rest on the vendor's servers. Unless the vendor stores no user data at, how does TLS protect that data?
Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.
Like I said I'm confused, genuinely trying to figure the article out.
"A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."
What is the cryptosystem then on the Web? Who is the entity? It's not the server or the Website so I don't see what's left except the browser and browser vendor.