Your colleagues may have seen only EJB2 and earlier versions that were truly unholy animals, which very few people used.
In EJB2, for the simplest things, a very invasive framework that was supposed to implement interfaces, with crazy life-cycle methods for which the developer had to provide an implementation, but the developer had nothing to do with the (business) goals. It was necessary to provide several such artifacts.
In addition, each bean must be stored in synchronization with records in a very detailed and hard to read deployment descriptor (XML file). As if this was not insulting enough for the developer, special tools should have been used to "improve" the bean and to create proxy classes, skeletons, and stubs. General OO things, such as inheritance, were not supported. There was some kind of injection, but strange, which existed in order to put things into some kind of map (actually a directory) associated with each bean.
The original EJB 1 model forcibly transferred all communications to the remote and all objects that should be distributed (EJBs were initially considered only remote access technology). To get the benefits of EJB, you were also forced to redistribute your architecture, even if it was completely unnecessary.
Perhaps the biggest insult to all was the concept of Entity bean (not to be confused with JPA entities). The bugs with this type of bean were so great that even the biggest supporters of EJB at that time could hardly recommend it to anyone.
Then, as a very practical issue, compatibility between EJB implementations was not very good, to say the least. Specifically, Entity Beans required a huge amount of vendor-specific configuration.
To cope with this, EJB implementation required supercomputers (in terms of installed sizes and required memory) of application servers, which were source locked and were quite expensive (thus not allowing companies to upgrade or switch because investments had to be returned first ) I don’t remember how many people wrote about technology at that time, and as far as I remember, the technology was mainly divorced by sales teams to managers of large corporations.
It is not surprising that the average developer did not really like this technology.
The sun realized just in time that the technology was moving in a completely wrong direction and was making a 180 ° turn and was embarking on large-scale reengineering work.
As a result, EJB 3 (2006) is a very smart and easy approach. No necessary interface interfaces are required for implementation, there is no XML required, only one bean must be encoded (just a simple POJO), standard default values are used everywhere (conditional configuration), no special tools are needed (normal javac will do), and use Simple Beans locally is actually a common case.
The essence of the Beans was so erroneous that they were completely discarded and replaced by a much more robust approach, protected by TopLink and Hibernate among others.
Combine this with a wide selection of free, lightweight, and open source software, combined with many renowned technology bloggers (e.g. Adam Bien, Rezh Rahman, Gavin King), and the return to popularity is easy to explain.
Recently, several Spring for Java EE migration guides have appeared, and they have received a very favorable vote on various news sites, many of which express their support for EJB as a very good technology Now. That would have been unthinkable half a century ago (when EJB 3 was only released and was not yet very famous).
The most common alternative to EJB is Spring Core (Spring Beans). At the moment, I think that there are no significant Spring advantages for EJB and vice versa. The two technologies are very similar. Spring offers a few additional utilities, while EJB is conceptually lighter (without XML). Both benefits are somewhat subjective. They are usually inspired by each other, and who is a little ahead, often depends on which technology last released a major new version.