I can understand the need for a UUID at the device level. It has to be uniquely identifiable from other devices when you're trying to reach that specific device. But it seems like entities such as services and characteristics don't really need to be universally uniquely identifiable, just uniquely identifiable among themselves.
The combination of <unique_device_id>+<internally_unique_service_id> should be enough to single out the service, and yet, services also need a UUID (as do characteristics, as do descriptors). Why is that?
UUIDs are no more than IDs in the Bluetooth Spec. Services, characteristics and many other things in the Bluetooth protocol stack use IDs.
Spec could have chosen numerical IDs using fewer bits, but then arises the central registry problem. UUIDs are used in a way any implementor can extend the spec-defined services, characteristics and other IDs without prior centralized allocation, yet with a minimal probability of collision (generating UUIDs in a way commonly accepted to produce an unique result is somehow a solved problem).
Note there is no UUID used for identification of a device. Device use BDADDR (like mac address), either centrally allocated (IEEE) or random (for LE).
See also: Bluetooth GATT service uuid overview