Before I answer: why are you asking this in response to the definition of a piece of technical jargon? What makes something "web3", and whether anyone should care about "web3", are separate questions.

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.