Sure, or you make a natural key. Depending on your RDBMS (MySQL and SQL Server cluster rows around the PK) and query patterns, this may be quite a bit faster, to boot. For example, if you have a table with customer orders, you could have a PK like (user_id, order_id), where both are INTEGER (this assumes that you have a centralized service assigning user ids, which isn’t that big of an ask IMO). Even if you used BIGINT for both - which is almost certainly not required for 99% of businesses for this example - that’s still 16 bytes, or the same as a binary-encoded UUID. Since most queries for this kind of thing will involve a user id, with a clustering index like MySQL / InnoDB, all of the user’s records will be physically co-located. Even for Postgres, which stores tuples in a heap, you’re not going to take a performance hit, and it’s a lot easier to read two ints than two UUIDs.
The problem is these performance boosts / hits don’t make themselves painfully obvious until you’re at the hundreds of millions of rows scale, at which point if you didn’t do it properly, fixing it is much more difficult.