The scenario
If you would have to rewrite the system from scratch, would you use EJBs again?
No: Don't answer this question, answer this one instead.
Yes: Provide one important, real problem that EJBs solved, based on your personal experience.
Let the answer contain just one problem. This will let other readers vote up the best feature of EJBs.
Well, this really depends on which EJBs we are talking about. I would say that MDBs can still be useful even now. For entity beans and session beans you can surely find a better approach. Maybe one feature which I still like in EJBs is scalability. Using "remote" option you can deploy EJBs to different servers if necessary. However, I don't think this is really necessary, and I've seen only one huge project where it was really useful.
I think it depends on what version of EJBs you're talking about. Let's discuss the only two relevant (IMO) versions.
EJB 2.1 might still be used by some people in a legacy system. They really have the most use as an RPC abstraction. They also provided a rudimentary ORM (Object-Relational Mapping) system as well. And as you mentioned, transaction support is provided. So if you were building a system where you wanted to communicate with a remote system, transfer object-oriented data and do it transactionally, you might find EJBs to be worth the effort. Otherwise, I'd say stay away.
EJB 3.0, however, has been greatly improved. It has all the features of the previous version, but does it in a more straightforward way. It also provides a fairly simple Inversion-Of-Control framework not unlike Spring, and a pretty decent ORM in the form of the JPA (Java Persistence API.) I have used EJB 3.0 and actually enjoyed it. You could argue for the use of EJB 3.0 the same way you would for Spring, plus it has a few more advanced, or enterprise-y, features available.
Did lots of work in the past with EJB 2.1, glad to leave it behind.
EJB value proposition remains true for 3.0, and carries a nice lightweight programming model. Transaction management, concurrency, data versioning, state management, these are non-trivial problems to solve correctly and Java EE frameworks continue to do an excellent job.
Admittedly, I use Hibernate and Seam to further build on some of the Java EE features, so it isn't strictly fair for me to say EJB 3.0 itself is the mecca. However I find too many developers throwing the proverbial baby out with the bathwater when they give up on Java entirely and move to something more vogue like Rails.
Seam provides a nice glue framework that keeps the amount of programmer effort quite low. Also lets you decide on a project by project basis when EJB makes sense versus POJOs, WITHOUT having to change your programming style.
One thing that has bitten many when using EJBs, or J2EE in general, is the dependency on the application server you're running your EJBs on. The appserver tends to be supported for a particular set of operating system releases and JVM versions. Not having the source code to a significant part of your runtime environment could also turn into a challenge.
While migrating from one vendor to another in principle is possible, you need to be very aware of small differences in how they implement the specification, and to stay away from vendor-specific extensions.
That being said, the appservers I've been exposed to can handle very much abuse from the code running in it and perform very well.
Convention over configuration.
The default behaviour of EJB 3 it's more often the desired one. I think the main problem with EJB 2.1 was the necesity of verbose config files, the new annotation-based configuration solve most of this problem.