Yes, it is an unfortunate design decision in the Microsoft implementation of the Kerberos protocol.

To interact with Active Directory and perform privileged actions, a service needs an Active Directory account that it can leverage for authenticated actions. This is colloquially referred to as a "service account", but it is not a special account type, it is just a regular Active Directory user or computer account designated for exclusive use by a service. Sometimes administrators will save time by registering a service under their own Domain Admin user account instead of creating a designated account for a service. This effectively makes their user account the service account. In other cases, extensive privileges may be required by a service (e.g. for network access control services, asset discovery services, vulnerability scanners, etc) and administrators find it easier to just create a Domain Admin (high privilege) account for that service than to do fine grained permissioning. This creates a dangerous situation where if an attacker can kerberoast the account associated with the service, they can immediately take possession of a high privilege account that can be used anywhere within the Active Directory environment.

> Since it's cryptographic signing, wouldn't this require reversing the hash?

Yes, you would need to brute-force it.

> Does any valid inverse of the hash work, or only the actual password that happened to get hashed?

Theoretically yes, any valid inverse of the hash would work, but to my knowledge there aren't any hash collisions for the NT hash algorithm. Practically speaking, this means that only the user's password would yield the correct hash.