Why? I have done this before and found negative much easier to use and understand. UUID have the nasty property that deny easy debugging, logging or any kind of HUMAN understanding...

Some of that depends on the version of UUID you are using. v1 and v6 UUIDs with timestamps can provide very useful for debugging. Of course v1 are problematic with MAC address embedding and v6 still just "draft/experimental" with the IETF.

My offline-first apps I settled on using ULIDs, which have time stamps and put them first so that they sort lexicographically (such as when included in string CouchDB/PouchDB _ids), and I've been pretty happy with that. That timestamp up front in the first few bytes can help a lot in debugging/"human understanding" of about where the ULID fits in a log stream.

I can also tell you at this point way more than you care to know about storing ULIDs in Microsoft SQL Server to get decent clustered index behaviors.

The primary benefit is theres no post-hoc reconciliation you need to do where you re-write all the foreign keys and object ids. It greatly streamlines the entire process, and lets you eliminate a lot of code / potential bugs.

I found it make far easier to see what object are candidates for sync, and to know the original row in the server.

I think makes a diference if exist a master database or if is peer-to-peer..

Yeah peer-to-peer is a different scenario. I'm assuming traditional client-server.