I think your definition is too rigid and unrealistic.
While this example is cherry picked, it’s practical and real world.
A studio is working on a project for a client. They want to share the work with the client. Setting up individual client accounts is both impractical and unnecessary. They instead opt for a single password to protect the project. This password is stored and shared by the client.
Eh, I have a hard time even granting this one exception. The problem is turnover—a single password is fine when it's an individual who purchased the software. As soon as it's a company a shared password becomes untenable because people who are not intrinsically part of the company will need to know the password, and those people can and do leave. The only safe way to handle this is to reset your password every time someone leaves, and that's not scalable for any business with more than a dozen people and a dozen vendors.
In your example, what path forward makes sense would depend on the project, but "single shared password" would be unsatisfactory to me as a client.
While this example is cherry picked, it’s practical and real world.
A studio is working on a project for a client. They want to share the work with the client. Setting up individual client accounts is both impractical and unnecessary. They instead opt for a single password to protect the project. This password is stored and shared by the client.