I read it is mandatory to have Global IDs in order to use Attribute Rules, is it? And why is that? I found no explanation in the docs.
Also read my question here please: Are Global ID preserved by the platform? - Esri Community
You will start seeing the reliance of GlobalId in the new built system as a globally unique identifier instead of the object Id. Utility Network, Version Management, Sync, and yes Attribute rules. The systems become so tightly integrated together it is just easier to always require globalId so those system can interact with each other effectively.
For attribute rules and validation and batch calculation in particular, we persist globalId of the source feature in the validation error tables. We also display the globalId of the feature that failed a constraint rule.
And to answer the question, globalIds are not preserved by default when transferring data, you will have to make sure its preserved by checking that box. It is not on by default so that it doesn't break old workflows.
For instance you have to preserve GlobalIds in the case of utility network because those globalids are referenced everywhere, but you don't necessarily have to preserve the GlobalId for tables with attribute rules
With the migration to GlobalIDs is there any plans to implement GlobalIDs as a true primary key in FGDBs? Currently, FGDB GlobalIDs do not support UNIQUE nor NOTNULL constraints. I support any replacement the 1980s ObjectID with either a UUID(4) or SERIAL(8) datatype.
I actually tripped over this the other day. "Preserve Global IDs" does not work with FGDBs. It only provides a message to build a new index with UNIQUE enabled but does not tell you it is unsupported in FGDB, nor does the "Add Attribute Index" command. After a couple hours of head scratching found a sentence buried in the documentation that they are unsupported.
While it is possible to enforce UNIQUE and NOTNULL constraints using Arcade, this seems extremely inefficient for something that should be supported by FGDB. Right now, just writing GlobalIDs to GUID fields to make a permanent copy. Also inefficient but better than the alternative that I could figure out.