Use case 1: javadoc lookup
Maven-aware IDEs don't suddenly notice that the dependency I have is JavaEE API
and switch to the right javadoc. This is certainly true for Eclipse and IDEA,
and I suspect it to be the same with NetBeans Maven support.
In those IDEs, if I'm writing my code and wanted to quickly check the javadoc of
those APIs, they need the accompanied source jar to be able to display them.
Ditto for figuring out the default parameter names when implementing/overriding
methods defined in the spec. IDEs don't use the bytecode for this, but instead
they do this by parsing the source files.
Use case 2: step executing inside spec classes
Some of the classes in JavaEE API have methods that are often worth executing.
When the debugger steps into those code, it needs the source files to be able to
display what's being executed. For this purpose, it's OK that javaee-api.jar can
be stripped — the debugger executes actual classes in the app server — but
you do need to have the source files.
The whole point of providing source jars is so that the necessary association
happens automatically. It's true that the user can get the complete GlassFish
source bundle and tell their IDEs to do the right thing, but the reason Maven
users use Maven is so that those grunt work can be handled by a program, instead
of using precious human time.