10 years later this is still an issue - for future people arriving here by search, I've made a post on the developer community API Endpoints section, check it on the off-chance there is newer information within https://community.xero.com/developer/discussion/131333596/

I agree, the Option's name is fragile, and would prefer having the ID in there. Our integration code could break if someone renames a Category option.

+1. This is just basic development best practices to use an ID rather than a label.

Since using names is too fragile, we opted to internally use Tracking IDs but map them to names at the last second by getting all the Tracking Categories and then associating the IDs to the name.

This isn't foul proof but it's certainly better than using names internally.

I want to add that we believe this to be a bug in the API

Presently the API for posting manual journals accepts tracking categories and options only by name using the "Name" and "Option" fields. It allows the "TrackingCategoryID" and "TrackingOptionID" fields to be entered and the API even validates that the format of these entries are properly formed GUIDs, but doesn't use them to determine the Category or Option to be applied.
The issue here is that the user can rename the existing Categories and Options and that breaks the interface unless you know that you need to update these also in your application; using the GUIDs overcomes this as it is a unique identifier and is not dependent on getting the names exactly right.