I'd say packaging is more important on a higher level, on the functional area than on architectual layers. Packaging on functional areas (checkout our guidelines on that in modularity) can prevent centralizations, and encourage developers to think more about the dependencies between functional areas.
But you're right in pointing out that our guidelines here are a bit confusing (i.e. with putting Commands inside infrastructure and then placing Commands inside the application package of the samples).
As our references show in some guidelines, we've tried to follow Eric Evan's Domain Driven Design definition. Below are some quotes:
Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems.
This layer is kept think. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an archtectual framework
Usually I find that infrastrcuture code is often extracted into code libraries that are shared either by all or a number of functional areas. This is theefore often very important code as many parts rely on it. It needs special attention on change control and quality.
Note that this is a guideline, not an enforcement. This separation only makes sense on a particular scale. i.e. if your functional area only contains 5 objects, you might just drop the last packaging by architectual layer. It is separation by type, not functional cohesion so we need to be careful not to divert to much from OOD practices.
Ok, great reply Alex, was really helpful. After expending some days using Cairngorm libs for real life project things got more clear.