I guess things are DB dependent. Spanner for instance not only recommends using uuidv4 as a PK, it also stores it as string(36). Uuidv4 as a PK works fine on Postgres as well.
UUIDs take up 36 bytes as strings so store them natively as 16 bytes instead if you can.
This is still 2x the space of an auto increment number.
This is overhead for every table, every index, and every relationship.
That might be acceptable in your case though, the case where it became unacceptable in my experience was in a MSSQL Express context. But it was an idiotic decision to use MSSQL to begin with in that scenario.
Regarding random clustered indexes. Broadly speaking you want your clustered index to be made up of some incremental unique set of fields.
I mean, technically there is not a massive issue, but the largest tables in your database will be the non-indexes (indexes are just tables) and you want your big, mainly append only, tables to be nicely compact so a bunch of space isn't taken up by half full pages.
But again, I should honestly have clarified that the problem was mainly an MSSQL Express problem where databases are limited to 10GiB.
You might honestly be fine, but do look for documentation on your specific database.
* Don't store UUIDs as strings.
* Don't use random UUID variants for your primary key (or don't use UUIDs for your primary key).
* Don't use a random column in your clustered index.