There is some great information available from the GORM Gotchas series. It's in three parts.
To answer your specific questions about Services and Command objects.
Q: "Should we always use command objects and Services?"
A: Some would argue that it's overkill to do so, however I personally think it's a great pattern and makes things much easier to test and extend. It may seem like a lot of effort but it does pay off in large projects.
Q: "Should we store command objects in session rather than domain objects?"
A: Store as little in the session as possible (if at all). If you have to store something there it's best that it be small and light weight. Command objects (typically) are going to be better for this than a Domain class.
Update (11/19/2014)
I'd like to highlight a very good series that outlines a lot of the potential issues faced using GORM and Hibernate. It's very long, but worth reading if you plan on using GORM/Hibernate in a large scale multi-user project. Don't be turned away by the negative approach because it does contain a lot of useful information.
I don't like Hibernate (and Grails), PART 1
I don't like Hibernate/Grails, part 2, repeatable finder problem: trust in nothing!
I don't like Grails/Hibernate part 3. DuplicateKeyException: Catch it if you can.
I don't like Grails/Hibernate, part 4. Hibernate proxy objects.
I don't like Hibernate/Grails part 5: auto-saving and auto-flushing
I don't like Hibernate/Grails part 6, how to save objects using refresh()
I don't like Hibernate/Grails part 7: working on more complex project
I don't like Hibernate/Grails, part 8, but some like Hibernate and Grails. Why?
I don't like Hibernate/Grails part 9: Testable code
I don't like Hibernate/Grails part 10: Repeatable finder, lessons learned