This doesn't make sense.

You said you were already using someone else's environment.

You can't later say that you don't.

Whether or not shell access makes sense depends on what you are doing, but a well written application server running in a cloud environment doesn't need any remote shell account.

It's just that approximately zero typical monolithic web applications meet that level of quality and given that 90% of "developers" are clueless, often they can convince management that being stupid is OK.

They do get to work on someone else's server, they do not get a separate account on that server. There client would be not happy to have them mess around with the environment.

By definition, it the client Alice gives contractor Mallory access to user account alice, that's worse than giving them an account called mallory.

Accounts are basically free. Not having accounts; that's expensive.

They specifically mentioned service accounts. If they’re given an user account to login as, they still might have to get into and use the service account, and its environment, from there. If the whole purpose was to get into the service account, and the service account is already setup for remote debug, then the client might prefer to skip the creation of the practically useless user account.

That's still not professional, but then again 99.9% of companies aren't.

Could you help me understand what assumptions about the access method you have in place that make this seem unprofessional?

Let's assume they need access to the full service account environment for the work, which means they need to login or run commands as the service account.

This is a bit outside my domain, so this is a genuine question. I've worked on single user and embedded systems where this isn't possible, so I find the "unprofessional" statement very naive.