See, I would be terrified of doing that because different RDBMSs and languages store and sort UUIDs differently. A UUID is not just a number. It's a structured data format.
Both MariaDB and SQL Server have dedicated data types for UUIDs, and they sort in an unexpected order if you're unfamiliar with the structure of a UUID or the endianness of certain portions of it. Oracle assumes it's going to be binary, but the generating function SYS_GUID() has some endianness issues you can run into. Meanwhile, PostgreSQL kist sorts them like a string!
Similarly, if you're using .Net to generate a native GUID type and passing that through your RDBMS provider, it may arrive and be stored differently due to that endianness problem.
Expecting that every SQLite database is going to be storing UUIDs in an identical manner seems insane to me.
Is it incorrect to simply sort the alphanumeric version of UUIDs? I am unsure if UUIDs have special sorting rules like Unicode.
It's not really about that.
It's the fact that, as the Base author, you don't really know how a given application might present a 16-byte binary version of a UUID to the database. If you don't know that, how can you reverse it to display the correct string representation? There are complications with byte groups potentially being in different places, and even the potential of mixed byte ordering.
How can Base make a 16-byte binary format that display both a GUID stored from a .Net application from person A, and also a UUID from a Python application from person B, and have the string representation be accurate in both cases? I don't think you can.
Off the top of my head, I can think of three different ways to store it in a single field: Big endian binary, little endian binary, or text. (Serious questions: Are there reasonable alternatives? Are people actually storing single UUID values across multiple DB columns?) That seems pretty simple for Base to add a display option... or add some "if-then" smell tests (shortly followed by an AI/ML cloud add-on subscription!).