hasOptedOutOfEmail is a field that is created from the Marketing Cloud Connect Managed Package and has effects on the integrated sends with Marketing Cloud, e.g. if you choose to send to campaigns / reports. It covers sends that initiate in Sales Cloud, but are performed in SFMC.
hasOptedOutOfEmail is set to TRUE when someone unsubscribes from any BU in marketing cloud, no matter how these are set up. Hence the MC Connect documentation states, it does not support multi-BU unsubscription.
"Marketing Cloud Connect doesn’t support business unit-level unsubscribes for Enterprise 2.0 accounts. Subscribers are included in the All Subscribers list at the enterprise level and unsubscribed from all business units in the enterprise."
https://help.salesforce.com/s/articleView?id=sf.mc_co_unsubscribes.htm&type=5
If you changed the user back to active on All Subscribers (again, in any BU context), there is no synchronization of this "resubscription".
It only mirrors unsubscriptions. That's why the connector comes with custom buttons introduced on the contact / lead layout, which respect both systems. Unless you press the "resubscribe" button, or change the hasOptedOutOfEmail field manually in SFSC, it is never set to "FALSE" by the connector.
Note the wording in the docs:
"doesn’t synchronize the subscriber status in the Marketing Cloud"
"The status of a subscriber changes from Active to Unsubscribed ..."
https://help.salesforce.com/s/articleView?id=sf.mc_co_unsubscribes.htm&type=5
===
If you send emails from SFMC that are not directly integrated, say, you synchronized contacts via the connector, and selected some based on SQL selections or similar, it actually has no effects unless you synch the field hasOptedOutOfEmail and purposefully make your SQL respect it.
(= sends that initiate in SFMC and are performed in SFMC >> no effect.)
If you send emails from SFSC that are unrelated to the integration, this field has no effect either. It's like you didn't have the connector installed, then the field wasn't even there. You can confirm this in a simple test by setting "hasOptedOutOfEmail" to true for yourself and sending yourself an email through SFSC through other SFSC methods than the ones from the connector.
(= sends that initiate in SFSC and are performed in SFSC >> no effect.)
===
So: You can master the "service email" permission in SFSC if that system decides what's going on for them, and sends them without SFMC in the picture.
By the way, if you involved Marketing Cloud you would likely define Service Emails as "transactional" and would not enforce Marketing Cloud's optin checks on All Subscribers either.
===
If an email is sent out via SFMC in any shape or form, whatever you define as your "master system" for unsubscriptions, the de-facto decisioning system or "gatekeeper" for emails leaving marketing cloud IS marketing cloud, because it will decide at send time what happens to an email. Unsubscription Status will be ONE piece of information for its decision.
See: Email Send does not send to everyone in Data Extension, no reason for Exclusion
If your "master system" (big quotation marks) is something other than marketing cloud, all of these factors will come on top of anything you define elsewhere.
===
Is it possible to have a single field that mirrors both platforms? No, it's not even possible to display on one field how marketing cloud alone will decide. You can create approximations, but SFMC will decide contextually, at send time. See: Is Marketing Cloud Subscriber Sendable?
