As service_errors exclude all expected errors, for history service, ShardOwnershipLost can be expected during deployment. Why it not exclude from list for metric service_errors.
See your point, but think its ok that its included as it can give you possible indication of customer impact.
For example query you alert on can be service_errors_with_type
for operations StartWorkflowExecution|SignalWorkflowExecution|SignalWithStartWorkflowExecution
and you can exclude things by error type for example
error_type!="serviceerror.WorkflowExecutionAlreadyStarted"
ShardOwnershipLost is kept in Serviceerrors because, even though it may happen during deployment and seem normal at that time, it can still point to a real problem if it happens in other situations. Keeping it in the metric helps you see the full picture of what’s going on in the system, and if it creates noise, you can always filter it out later while setting up alerts.