Any version of UUID except v4 on the client side would be a mistake- as you are relying on it to provide extra information such as a timestamp which might be manipulated.
Of course, UUIDv4 on the client side is not without risk either- needing to validate uniqueness and not re-use of some other ID. For the UUIDv7 on client side- you could add some sanity validation- but really I think it’s best avoided.
There’s a whole bunch of use-cases where the ability for a user to mess with the timestamp is not a problem. Who cares if a user screws up the ordering of items in a collection only they see? But if you can attack the private key by generating many different ciphertexts for the same rand, that might let you defeat the purpose of this masking.
I concede my above comment was speaking in generalities and has plenty of exceptions. However, I do prefer to fallback on safe defaults, and letting the client choose the UUIDv7 could certainly have some unsafe consequences.
What if a broken client implementation uses the same client ‘generated’ UUID (or very similar) for all client requests?