UUIDs instead of per-table autoincrement keys seem to be a solution which covers the part of the problem that involves DB support as opposed to data model design, and several DBs have adequate support for UUIDs.
With autoincrement keys, you need to either contact the database server for each data object you create, or implement complex logic to replace temporary IDs with database IDs later.
Always keep in mind that anything coming from the client cannot be trusted.
But I find that the security checks against "stealing UUIDs" are much simpler to implement than a system of composite primary keys (deviceid+autoincrement or userid+autoincrement) or some sort of temporary primary keys. If you see suspicious UUIDs, you can just discard the data.
Having the client generate the "final" IDs for objects is particularly convenient when the client can produce a complex graph of objects offline, for example an order + order items + comments + more. If using temporary IDs until first contact with server, all these links would have to be patched up when the objects get real server-side-assigned IDs.