Both of those solutions typically make it hard for a DB if you write new entries, assuming you have an index on the ID.
In addition it might be more calming to actually be sure that a particular ID is not in use without doing a round-trip.
Is it practical to pre-allocate empty entries and reserve a set of them?
Lots of languages are catching up to UUIDv7, which solves the indexing issue.
This is only a problem with extremely big indexes.
Now in many, typical applications you'd have to scale up quite significantly before this becomes a problem.
But if your application requires you to store small, new entries very quickly, you'll start to notice this even with moderate scale. Disk persistence is often the bottleneck already, and this might make it worse.
One fun and useful reference: https://devblogs.microsoft.com/oldnewthing/20190426-00/?p=10...
It's particularly interesting that Microsoft SQL Server was designed to optimize indexing for UUIDv1 machine IDs. That makes a certain amount of sense for a database cluster if IDs are sorted by machine. Of course, developers don't let developers use UUIDv1 in 2023 because those machine IDs are not secure in a general sense and can be a privacy/data leak in the worst cases.
Other databases sort/index UUIDs differently. There's no real "standard" and optimizing the storage of a UUID key is a game of playing to the strengths of your specific database.
(On one project I put some work into matching the much-better-defined ULID sort order to MS SQL Server uniqueidentifier columns for better database locality.)