I think that Atlassian do conform to the standard to the extent that the standard defines. Despite this, variations in behaviour between application-server implementations are sufficiently numerous to make testing an application on all of them difficult. One might say that the Java EE compliance test suites are not rigorous enough, or that Atlassian have been forced to rely on behaviours not addressed in the specification. In any case, the situation of Java EE standardisation appears not to be meeting the needs of Atlassian, who have a significant product(s) on the Java EE stack. What are they to do when their application runs on 3-4 application servers, but not on a fifth?
Naturally, this comes back on us poor sods who want to deploy Java EE applications in Java EE containers, because dammit, that's the whole point after all. But I hesitate to point the finger at Atlassian, and the company who might have been in a position to act has just been subsumed by a giant that is showing little interest in open specifications.
IMHO, Java EE has always had a fail when it comes to deployment. I submit that it's fully ludicrous that in order to get Atlassian to run on a generic app-server, one has to extract the WAR, hack up some files, and run a make script! That's a fault of the Java EE specification, not paying adequate attention to the deployment lifecycle. It seems that after EJB 2.0, everyone in their haste to put the knife into JDO (may it rest in peace) and foist EJB 3.0 on the world, forgot about the foundational separation of roles which was the big news of J2EE as far as the enterprises were concerned.
What to do about it? Say thanks for the API's, code your product for a high-quality app-server that meets your licensing needs, and make customers run the whole box and dice in virtual machine container instead of a Java EE container.
Java EE is dead.