In Bluetooth, attributes types, GATT service types, characteristic types and descriptor types, and other constants are identified through UUIDs.
UUIDs are no more than identifiers, 128-bit identifiers. One given 128-bit value designates one given thing. Using 128-bit random values gives minimal chances of collisions for two parties generating identifiers on their own, without the need for a central registry.
UUIDs in Bluetooth
Bluetooth standard-defined UUIDs receive special treatment as they are commonly used throughout the various protocols of the Specification. They are grouped around the Bluetooth Base UUID (xxxxxxxx-0000-1000-8000-00805F9B34FB) and share 96 common bits. (See core specification, 3.B.2.5.1)
In various protocol parts, standard UUIDs can be transmitted in a short form, skipping the common bits, thus only using 16 or 32 bits on the air. This is an implementation detail, specific to some protocols in the whole stack. Because of this, standard-defined UUIDs are often referred as Short UUIDs.
Apart from standard UUIDs, any implementor is free to generate its own UUIDs from 128 bits of random and use them anywhere needed. Custom UUIDs must not use the Bluetooth Base UUID (and cannot be encoded in a short form, but you should not care about this).
Implications for custom services
Use Standard UUID when implementing standard services and characteristics.
Never use Bluetooth Base-UUID based UUIDs for custom purposes.
When developing your custom service and attributes, reusing existing UUIDs (or part of UUIDs) from code you may find in example code, vendor SDKs, or anywhere else is not a good idea. You should really regenerate yours.
Side notes
Specification does not define any grouping scheme (what you call prefixes) for custom UUIDs, but some vendors do incitate to group custom UUIDs, in a way they generate one 96-bit custom base UUID, and issue incrementing values from this, as Bluetooth did. This is not standard and brings no protocol optimization.