Answer
Publishing a Custom Object triggers several concrete server-side actions: generating and deploying the underlying database objects, granting access to privileged system users, refreshing the Dictionary Cache, and creating and granting a new Presentation Object to every role that already has access to any view belonging to the extended Logical Unit. Unpublishing is the more disruptive direction specifically, since it removes the deployed view and package, though not the underlying table, from the server — meaning any OTHER Custom Object referencing an attribute from the one being unpublished immediately stops working and starts throwing errors. For a Custom Object actively used on a screen end users are currently working in, an unpublish-then-republish cycle can feel like a temporary mini-outage for that specific screen while it's in progress, since errors can surface mid-cycle and users may need to wait until publishing fully completes, with no guaranteed clean rollback if the process is interrupted partway through. Recommendation: whenever a change to a Custom Object requires an unpublish/republish cycle, rather than a pure first-time publish with no unpublish step, do it during a scheduled maintenance window or non-peak time, rather than while users are actively working with that specific object.