In general, it seems not advised to inflate objects unnecessarily by giving them multiple equivalent unique identifiers, when one is enough. It would be a redundancy.
However, there are a number of reason that could justify the situation that you describe (I’ll illustrate the ideas with some general examples without guid but with a similar ratinale):
- Legacy: the system was build with one id (e.g. an internal one); there are hundreds of systems that use it that can’t be updated at once (i.e. backward compatibility); there is the intent to use a better id; so for a given time you need to map both.
- Ownership: the system does not own data it manages (or its external identity) and needs to keep track of the identities known elsewhere. A typical example is a personal id in a payroll system, that uses a unique social security number that is managed by a state.
- Semantics and/or bounded contexts: although the identities look redundant, in reality they aren’t. One example are an internal vehicle id in a fleet management system that is mapped to a registration plate. Both uniquely identify the same car, but for different purpose (and one can change, for example when a vehicle is sold/transferred to another subsidiary). Another example is when multiple external identities may refer to the same internal identity or vice versa, because each identity is managed by a different system and it is preferred to keep the model of each system independent.
- Distributed computing: where several subsystems may create entities independently, and at a later stage, some other subsystems merges/aggregates the data.
- Performance?: GUID produce longer strings (in a web api), and use 2 to 4 times more space in binary. I personally don’t think that it would be a dramatic difference, but maybe some other people think it will (or have evidence it will?). This is why I mention it with a question mark.
Edit: As Allon Guralnek pointed out in the comments, if the database uses clustered indexes or index organised tables that order rows based on the primary key, the use of a GUID could create some extra sorting overhead at every insertion due to the randomness of the GUID. But in this case, there must be another reason to justify keeping the GUID. - A combination of several factors.