In general, .z functions (not .z variables) are encouraged to be overwritten as is. For example .z.pg, .z.ps, .z.pc, .z.po etc. In fact you can't trigger such callbacks without modifying the vanilla functions. Your example of .z.u is a bad example, it's not a function so you can't replace it with a function/logic of your own and even if you could it ignores overwrites:
q).z.u
`tlynch
q).z.u:`ABC
q).z.u
`tlynch
For .Q functions it is possible to overwrite and/or create your own but it is usually discouraged.
In terms of how to handle a codebase which references a lot of these built-ins, personally my preference it to allow each individual script/user use the known built-ins rather than soulless .util functions. Otherwise reading the code becomes a tedious exercise of .util lookups (who needs .util.plus?!). Of course that then means that to control certain behaviour (particularly after it's already written) you need gain control of the primitive, with the alternative being to modify many scripts in many places. Again, it's often down to personal preference since in most cases it's possible to do it either way.
One final point to add, sometimes it can be useful to retain vanilla behaviour when gaining control over a built-in. One sensible way to do this is to pass the vanilla function into your custom function and applying the vanilla function within yours. For example
.z.pg:{[orig;x] myotherlogic[];orig x}[.z.pg;]
This essentially snapshots the existing .z.pg as "orig" and applies that built-in logic within your custom function. (just be careful if this override runs twice then you'll be snapshotting the custom logic, not the original)
