Your coworkers might have seen only EJB2 and earlier, which indeed were unholy beasts that very few people enjoyed using.
In EJB2, For the simplest of things very invasive framework provided interfaces had to be implemented, with insane life cycle methods for which the developer was required to provide an implementation, but which had nothing to do with the (business) goals of the developer. A few of such artifacts had to be provided.
Additionally every bean had to be kept in sync with entries in a very verbose and hard to read deployment descriptor (an XML file). As if that wasn't insulting enough to a developer, special tools had to be used to 'enhance' the bean and to generate proxy classes, skeletons and stubs. Common OO things like inheritance wasn't supported. There was a kind of injection, but a weird one that existed of putting things in a kind of map (directory actually) associated with each bean.
The original EJB 1 model enforced all communication to be remote and all objects to be distributed (EJBs were originally seen as a remoting technology only). So to get the benefits of EJB you were also forced to make your architecture distributed, even if this was completely unnecessary.
Perhaps the biggest insult of all was the concept of the Entity Bean (not to be confused with JPA entities). The faults with this type of bean were so great that even the biggest supporters of EJB at the time could barely recommend it to anyone.
Then as a very practical problem, compatibility between EJB implementations was not very good to say the least. Especially Entity Beans required massive amounts of vendor specific configuration.
To top it all off, EJB implementations required heavyweight (in terms of installed size and required memory) application servers, which were closed source and rather expensive (thus preventing companies from upgrading or switching because the investment had to be first paid back). I can't remember many people blogging about the technology at the time, and as far as I remember the technology was mostly pitched by sales teams to managers of big corporations.
It's not surprising that the technology wasn't really loved by the average developer.
Sun just in time became aware that the technology was heading in a completely wrong direction and did a 180° turn and started a massive re-engineering effort.
As a result, EJB 3 (2006) is a very sane and lightweight approach. There are no required framework interfaces to implement, there is no required XML, only a single bean has to be coded (just the simple POJO), there are sane defaults everywhere (convention over configuration), no special tools are required (normal javac will do), and using simple beans locally is actually the common case now.
Entity Beans were so flawed that they were dropped completely and replaced by the much saner approach advocated by TopLink and Hibernate among others.
Combine this with a wide availability of free, lightweight and open source implementations, in combination with many well known bloggers advocating the technology (e.g. Adam Bien, Rezha Rahman, Gavin King) and the rise back into popularity is easy to explain.
There have been a number of "Spring to Java EE" migration guides published recently, and those got a very favorable number of votes at the various news sites with many people expression their support for EJB as being a very good technology now. This would have been unthinkable half a decade ago (when EJB 3 was just released and wasn't very known yet).
The most common alternative to EJB is Spring Core (Spring Beans). At the moment I think there are no definite big advantages Spring has over EJB and the other way around. The two technologies are very similar. Spring offers some more convenience utilities, while EJB is conceptually more lightweight (no XML). Both advantages are somewhat subjective. They typically are inspired by each other's functionality and who is slightly ahead often depends on which technology has last released a major new version.
