[Baertram]

The addons will be loaded from Z (ZOs) to A.
In addition the load order dependes on the defined ## OptionalDependsOn or ## DependsOn tags in all addons and libs (also addons).

In the addons it's important then where you do the hook.
In event_add_on_loaded, somewhere in any addon file in a ddo ... end statement (loaded even before event_add_on_loaded) or later at event_player_activated, or even any other event liek a special crafting event -> 1st call -> apply hook.

This all matters and defines which will be "the first".

If you use Zo_PreHook to hook the vanilla code and do not return true all other addons + vanila code will be also run properly!
If you use SecurePostHook or ZO_PostHook there is no way to suppress the call to the vanilla code before as you are hooking "behind" it.
Still breaking the code there could destroy other SecurePostHooks or ZO_PostHooks which are run after your addon, due to the load order etc. described above.

If you overwrite the vanilla UI code, like you have done above, you replace the original function.
-> In most cases there is no need to do this! Just use the proper hooks provided and watch that your return isn't using true so that following hooks and vanilla code will run as well. Only use the return true if you really want to abort some function on purpose there.
If you have overwritten the function and another addon later hooks into it, it wil hook into your function.
If hooks were already applied to the vanilla function you will take them with you in your call to "originalFunc" (orgLayoutAchievements in your example).
-> I'd change this to a normal ZO_PreHook again if your code above orgLayoutAchievements is the vanilla code. If you need to change variables and values in the original vanilla code, like add another function call within some nested lines, which cannot be done as a prehook before the vanilla code runs, than an overwrite is often necessary).

Depending on WHERE you overwrite something, e.g. in the "base class" like ZO_Smithing, or the created object SMITHING, it might even break other addons as well. e.g. you hook into ZO_Smithing and change values. Others hook into the created object SMITHING (which will be later, after ZO_Smithing) and want to do something which you have changed already -> lua error.
Either all hook the same class OR object, or need to test and talk to each other, change the ## OptionalDependsOn to change the load orders, and so on.