Original summary: GreenHopper misuses the concepts of "epics" and "themes"
–

An epic is a placeholder for a collection of user stories that will eventually be defined (this has to happen before they're added to a sprint). Epics can be prioritized in the Product Backlog, along with all the other Product Backlog Items.

A theme is a coherent set of user stories – Often the resulting user stories from an epic. You can't prioritize a theme per se, because its Product Backlog Items may not necessarily be in a consecutive order.

GreenHopper is mixing the two concepts, leading to the following issues:

1. You can't prioritize an epic (the issue type) in the Product Backlog. They don't even show up in the Product Backlog.
2. The "epic" functionality is in some aspects confusing and cumbersome, because it mainly deals with themes, while also assuming that epic = theme. One consequence is having a redundant "Epic Status" field that users must somehow keep in sync with the "Status" field.
3. You get a separate pseudo backlog for "epics", which allows you to prioritize them. This doesn't mean anything in Scrum.

Older versions of JIRA/GreenHopper used to get these two things right, albeit with an interface that wasn't as helpful as the new Rapid Boards: Themes were a type of label and epics could be prioritized.