The newer automation tools benefit from being newer; They can take advantage of hardened, well designed interfaces (like the Dev Tool protocol). Selenium's been around for a bit longer, and was built when browsers didn't make it easy to control them. That's influenced the semantics of Selenium quite a lot, as well as explaining the extra moving parts (Drivers exist to map the Selenium Wire Protocol (or W3C protocol) to whatever they're driving because Selenium wasn't built with a specific browser in mind).
I feel like, at this point in time, the real difference is how much abstraction you want from the browser. Selenium is a set of knives, Puppeteer is a Die Cutter. You'll put in more work with Selenium, but maybe you need something do happen a REALLY specific way. Or, you might just need shapes cut, and Puppeteer will be more reliable and faster.
Selenium uses a chatty HTTP interface, whereas puppeteer/playwright use WebSockets or pipes to communicate. Under-the-hood, however, Selenium is simply using chrome's devtools protocol to communicate with it. The way selenium does this is by another binary, generally a `driver`, that has the protocol "baked" into it and has the HTTP selenium API as its input interface.
This is all a long way of saying that puppeteer/playwright have a lot less moving parts, and are generally more approachable. Selenium _does_ have a lot more history behind it, better support across languages and frameworks, and is more stable but it's also much larger and "clunkier" feeling. It's also a lot harder to scale with load-balancers since, again, it's all over HTTP so you'll need some way to load-balance with sticky sessions.
Practically speaking they all do the same thing at some layer. Both are high-level APIs around the devtools protocol, it's just what higher-level interface you prefer and what your language/runtime is.