The best practice stated by Microsoft when dealing with security roles is not to create security roles underneath the root business unit of your organization. Each security role defined at the root is inherited by its child business units. In the case of a new organization the roles you get will be the out of the box security roles. The interesting thing about this is as a developer is that the UI deceives you into thinking that when you are looking at security roles that there is only one when in fact much like the Cylons in Battlestar Galatica there are multiple copies. What is happening behind the scenes is that for each child business unit the security role is being duplicated down the business unit hierarchy. If you are asking yourself why you should care then you have to consider instances when you want to know information about certain security roles in the system. If you are ever in a situation where you are looking for a security role by its guid like in a configuration setting you'll have to keep in mind that you can't just copy the guid you find in the interface and expect that it applies to all business units because they are all unique records with their own guids in the database.
 
As of right now I would say the best way to grab security roles is somewhat unfortunately by name. At least the name is guaranteed to be the same in all the child business units. The problem with this approach is of course if you ever change the name of the role you are screwed with any code that relies on that name to be something specific. Just to prove the point I conducted a little experiment with a user to see what happens when I moved them from one business unit to another and reassigned them the same exact security roles.
 
In the following example I have user Kara Thrace who is a member of a business unit that is changed to a second unit. You would expect that her security role guids would remain the same, but as you will see even though she was assigned to what appears to be the same exact security roles in the CRM interface they are actually Cylon copies that only appear to be the same thing.
 
Security role guids as member of business unit Galactica
Viper Pilot: 086F539E-46B4-DF11-B769-005056A97446
Lieutenant: A62D06E2-43B4-DF11-B769-005056A97446

Security role guids as member of business unit Pegasus  (Hey these aren't the same security roles!)
Viper Pilot: 325585EC-E71F-4FF2-B419-3AAF9C3690AF
Lieutenant: bF6E95E97-7BC8-41D3-B1ED-F172D51752D6

The bottom line is keep in mind how security roles are implimented in the database so that you don't get caught trusting a Cylon security role and wonder why your code isn't working correctly.