Disadvantages of a non number key field

As long as the key field uniquely represents a record and its child records have that key field value to be able to relate it, you should be fine. Is the key field system generated or provided by the user ? 

The only real one that I can think of is that if you have a Child table with text fields which need to be floated up to the Parent with a Reverse Relationship,  that you not be able to built the reverse relationship to do that.

 One of the biggest draw backs I have seen in practice when using a Text field instead of the default (Record ID#) has been updating if a text value changes. As an example when working with a builder who used their Location Name as the key field for their records they had an issue when several locations updated their name. When they updated the name on the Parent Records since it was the key field all the child records in several tables were orphaned as the Location Name didn't automatically update on all of their existing child records. In order to match those records back up they had to find the child records in each table tied to the previous Location Name and update the Location there as well.

This lead to some confusion by their users until it was resolved. Text field keys are sometimes more prone to needing to be changed like that if they are being drawn from values like Customer Names, Company Names, etc that can change naturally over time instead of a number of SKU that should remain fixed. They decided to keep their existing structure and go through the update process but I know for some they would prefer to avoid that need entirely by not basing their relationships on a key field that is prone to change, especially changes outside of their control. 

Thanks everyone!