This may be standard practice for some but several times I have experienced problems related to this

When deployments are performed in Microsoft Dynamics any workflows, settings records, or case creation rules for example, which get created during that deployment are set with the user performing the deployment as the owner. If that user doesn’t have sufficient access permissions at any time related processes may begin to throw errors and impact process in the system

What I have experienced several times is project users do deployments to production with their personal user as the owner. This is fine for a duration of time, but at some stage later down the track that individual moves on, has their user disabled, and the system starts throwing confusing errors related to missing security. These can take a while to identify, and fix, and require assigning those processes to different active users

Where the deployments are done with a service account this risk is very low as service accounts are more unlikely to get disabled

A service account requiring a licence merits consideration, but in alot of cases a service account is required anyway for administration, integrations or other processes so may not actually mean extra licenses are required

That’s all folks