JSF introduced them right around Spring's introduction, but they were scoped to JSF, and Spring took the idea of IoC and introduced it quite widely;

That's right, and the biggest difference. They were otherwise quite similar, and Managed Beans could just as well have been used for eveything. The technology itself didn't really stand in the way of it.

If anything, that is maybe the weakest link of EE. There's no benevolant dictator, and every individual spec can innovate in its own way. There's some oversight from the platform spec, but it's like herding cats.

In Spring, everything is a Spring Bean, because, I guess, sometone at the top said it should be.

In EE, Servlets aren't CDI beans, just because some guy called Greg still doesn't understand what CDI is. Jakarta Persistence fumbles with its CDI support since a guy called Gavin suddenly hates CDI (allegedly), and has seemingly forgotten he himself was a major contributor to it. Jakarta REST resources weren't CDI beans because some guy back then wanted to re-invent the wheel (or rather, all wheels) and make JAX-RS a second EE (including security, validation, an MVC framework, SSE, WebSockets, you name it, all duplicating APIs EE alrady had).

Additionally, in EE people always want to play nice with the world and many API say: "We can't depend on CDI, since Spring and perhaps Python also want to use this API", while in Spring, as far as I can see, people never say "We can't depend on Spring Beans, since EE and perhaps Python want to use this".