Fallacy 5: JMS, JCA, JTA, JNDI, XA are too complex, too heavy and aren't needed at all. 📎
JMS: the JMS-API is not complex, but you need some lines of code to write, until you are able to access a destination. This redundant code can be of course easily encapsulated. Frameworks like Spring already provide some simplification (JMS-templates). In Java EE 5 the JMS resources can be easily injected - so error-prone lookups are no more necessary. But this is only "syntactic" sugar. The real value of JMS are: persistent queues, durable topics, transactional behavior, pub/sub capability and rich monitoring. Things like "once and only once delivery" are hard to implement without JMS, and can be easily configured in JMS. Because of some cross-platform products, JMS can be easily used as an integration framework (you can easily communicate with old legacy systems, without knowing it...). So from this perspective JMS is great and comparing the API to the underlying functionality also extremely simple to use.
JCA: Java Connector Architecture is a connector framework. It is similar to JDBC and allows "easy" communication with backend legacy systems. Some systems, like e.g. SAP, already provide an implementation (in this case called JavaRessourceAdapter). Connector can be easily deployed, than you are able to access the backend data - without additional hacking. JCA connectors can be transactional, they care about pooling etc., so lot of work is already done. To communicate with SAP you only have to know the system parameters. I did it in a training with my students, the complete procedure (download, installation, writing and deploying a sample application) took less than one day it was much easier than existing alternatives (JCO or proprietary connectors).
JTA/XA: it's classic: many developers still believe, that transactions are only needed in big enterprise applications. In fact you even need a transaction in read-only applications in case DIRTY-READS or NON-REPEATABLE-READS are not an option. The cool story: with session beans you do not have to care about transactions - just declare them as an annotation. Everything else is done by the container. An alternative is a real pain: you have to fetch a connection associate it with a thread commit it after successful return and rollback it in case of an exception. XA or two phase commit: it is not possible to provide a working alternative in a project, we had enough to make existing solutions work...
JNDI: is really simple. Nothing else than a distributed, but not transactional map. You need only to know one method: lookup - and will get a reference back. In JAVA EE 5 resources from JNDI can be easily injected - so event the lookup invocation is no more needed. JNDI was often criticized, but from my perspective it was never the reason why some projects failed :-)
Conclusion: For real world enterprise applications most of the functionality of the Java EE 5 APIs is simply needed. The "enterprise" APIs do often abstract established products and industry standards - which are complex. The complexity comes from distributed data processing and not the API so replacing Java EE with some other technology is not an viable option. Also .NET and other frameworks provide very similar functionality. Of course most of the enterprise APIs can be simplified or improved, but this was never a problem in my projects. We have to struggle with other challenges like: deadlocks, XA between oracle and informix, asynchronous communication with unreliable backends etc.
It seems like some developers use Java EE for the implementation of "guestbooks" and than criticize it. Java EE can be very lightweight: just use an JSP with SQL JSTL-tags - you are able than to read a database table and display it in browser with few lines of code :-). You even do not have to compile...