Seems to me that Web3 is focused on Etherium, which is definitely a specific kind of 'P2P' if you want to use that term.
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'.
Most substrate technologies are not, on their own, "problems that need solving." What real-world problem does TCP solve? WebRTC? ICMP? Nothing, without application-layer protocols on top of them.
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.
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'.