Nevertheless, the answer is: because web standards don't allow browsers and other only-speaks-HTTP clients, to interact with regular peer-to-peer protocols, preventing them from participating in [the existing networks serving] peer-to-peer use-cases. You can't write a blockchain node as Javascript that executes in a browser and have it talk to the same network peers that other native nodes for that chain interact with.
Instead, if users want to participate in such use-cases (e.g. to download a torrent on a Chromebook), they must use technologies like WebTorrent, that stand up their own, incompatible p2p networks based on WebRTC and other web-specific carrier protocols. This creates isolated "web p2p" networks (e.g. the WebTorrent swarm) divorced from their regular-p2p equivalents (e.g. the BitTorrent swarm.)
Web3 is one way of avoiding this network split: it is a [nascent] set of standard APIs, allowing browsers and other only-speaks-HTTP clients to interact with p2p protocols by holding relationships with "p2p protocol 'light client' over HTTP" gateways, that expose the p2p protocols in standard useful-over-HTTP manners to browsers.
Another way of avoiding such a network split, instead of web3, would be creating lower-level gateways that allow browsers and other only-speaks-HTTP clients to directly tunnel p2p wire protocols over HTTP, where the gateway would terminate the HTTP tunnel and then route the p2p packets to peers as normal.
However, most p2p protocols are a really bad fit for having all communications linearized into a TCP stream. Peers connected through such gateways would be really badly-behaved peers from the perspective of the network.
Web3 "solves" this by not having the browser speak the p2p protocol itself, but instead having the gateway speak the p2p protocol and act as the finite-state-machine keeping the p2p state, while the browser just gets to interact with the state model that the gateway node builds up through its p2p interactions, via either RPC request-response flows, or event streaming flows, both of which are much better behaved over an HTTP carrier than p2p traffic generally is.
That 'broad generalized use-case' you articulated isn't really a 'use case'. It's not really a problem that needs solving.
And of course a browser plugin solves can get around those problems.
The issue is that this entire stack of technology doesn't do anything that people really need or want. Etherium is popular among Etherium enthusiasts and a few speculators for interests sake, not for for the sake of any actual 'use cases'.
These low-level protocols are essentially frameworks for building solutions, solutions that take a standard shape specified by the low-level protocol, and thus allow for standardization in libraries and tooling.
Web3 is a substrate standard, a specification for how browsers should frame RPC and event-streaming requests to "p2p 'light client' HTTP gateways". It's not an application-layer protocol.
Ethereum's RPC protocol is an example of a Web3 protocol, just e.g. SMTP is an example of a TCP protocol.
Web3 is a nascent concept, in that it doesn't really have other things built on top of it yet. Its implementation is a de-facto outgrowth of what people did when building the Ethereum protocol. But the concept of "a Web3 protocol" isn't definitionally tied in any way to the Ethereum RPC protocol, any more than TCP is tied to whichever application-layer protocols it co-evolved with. (TELNET was a major one, I believe.)
Web3 can be a useful framework even if the only thing people have built on it so far (Ethereum) isn't useful. (I won't claim one way or the other whether Ethereum is useful; I'm just pointing out that believing one way or the other about Ethereum being useful is irrelevant to whether Web3 as a low-level protocol is a useful tool for building protocols.)
> And of course a browser plugin solves can get around those problems.
Browser plugins do not practically exist any more. The era where you could ship an experience requiring users to install a plugin like Flash, and actually get adoption, is gone. Now a majority of browser installations in the world are inviolate apps running on a phone or tablet or Chromebook (or desktop PC with an App Store and code signing), where the device doesn't allow the user to embed other native code to run in the context of the browser. Only weak extension APIs are supported, and these intentionally do not expose features like speaking arbitrary L4/5 wire protocols.
The problems browsers have, can now really only be solved either by browser manufacturers themselves (as in e.g. the browser U2F API), or by operating entirely "above" the browser by using HTTP to communicate with gateways that do what the browser cannot.
