An Enterprise Archive (EAR) is effectively a ZIP archive with predefined structure. An EAR contains one or more WARs and one or more EJB-JARs. However: most of the EARs contain exactly one EJB-JAR and a single WAR.
Starting with Java EE 6 you could use WARs instead of EARs for the mainstream Use Cases. However, requirements like deployment of an embedded JCA connector, shared libraries or bundling multiple WARs per application, still require EARs.
According to EAR's nature you will have to create a ZIP three times to deploy your application; the EJB-JAR, WAR and the EAR itself. It takes almost three times as long to build an EAR, than a WAR. The application server will have to extract the archives to deploy the application as well. EAR requires to deal with more projects in the IDE: EJB, WAR, EAR and usually an assembly project which holds everything together.
An EAR increases complexity of development, by increasing the number of artifacts the developer has to deal with. You could equally well start with a WAR and create EAR later on demand.
WARs are sufficient, but even their size matters. A Java EE project is going to be deployed several times locally, and on each commit on a Continuous Integration server. The smaller the WAR the faster the deployment and feedback from CI. Minimizing external dependencies makes the WAR smaller and development faster.
If you already committed to use a Java EE server--use it. The more Java EE functionality is used in production, the less dependencies you need. Especially "just for fun" dependencies should be eliminated. External dependencies should be treated as marketing emails; http://en.wikipedia.org/wiki/Opt-in_email and not Opt-out; think twice before you add a new dependency to the project.
WAR sizes are directly related to deployment speed and so productivity. Also optimizing the performance of a CI environment is an Obvious Way To Save Money. Stay fast, stay lean!
NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.