No. In scenario 1, with TLS, an attacker gets access only to data corresponding to incoming requests. The same thing clientside Javascript cryptography code does to push secrets out to the client (either by deriving keys from memorable secrets or using local storage) works to store secrets serverside encryption can use; lots of encrypted cookie systems have been built to do this.

Your scenario 2 analysis works by suggesting that attackers can't easily subvert the Javascript contexts of clients (it mentions for instance "resource integrity"). But every request for any resource that alters the DOM or loads code allows an attacker to pull this off; it's the premise of the attack. This is an even weaker case for browser JS crypto.

I think the big premise mismatch we have is that you're assuming I'm saying "just use TLS and store keys on the serverside".

I feel like discussions about WebCrypto always fall apart in arguments over abstractions, like software update versus HTTP requests. But I'm saying, it seems like you can literally just skip all the clientside cryptography, stuff keys in cookies (or whatever), and do all the encryption serverside, and end up with the same threat model, which to me is telling.

I don't think people are crazy for pushing back on this. People smarter than me disagree about it. I wonder if David Adrian wants to take a swipe at this argument.