Currently replication and sharing is configured at the class level, however it would be nice if that was done at the system level. Potential use case where the DB administrator is not the person that creates the classes however the person that creates the classes does not care or does not know about replication and sharing.

Quoting @etiennedi on slack:
Pro class level
I’m aware of many users that use classes for multi-tenancy, i.e. one or multiple classes per tenant. For this it makes a lot of sense to be able to configure this separately. A large tenant may need a completely different config than a tiny one, etc.

Pro systems level
Besides the “different personas” argument you make, another one would be our situation on the WCS/managed offering. There the promise to the user is that they don’t have to worry about anything infra-related and in fact whether or not they choose HA even has an effect on the pricing. So, we need something that is not at the class level.

I have two potential ideas, I like the second one better than the first, but the first one is much cheaper to build. So it could be a matter of going with option 1 at first and option 2 later:
Option 1: System level default, optional class-level restriction
The idea is that an administrator could set defaults for this config and then the user can override them. If we don’t want the “class creator” to override this we could also protect those settings. Then the class creator has to omit them or face an error message. <-- cheap to build, non-breaking would solve your issue. Doesn’t solve the multi-tenancy issue.
Option 2: Introduce proper namespaces
If we look at Cassandra, for example, replication is configured at the Keyspace level. A keyspace is a collection of various tables. I could imagine that we could introduce the same concept within Weaviate as well. Create one “keyspace” per tenant and have complete isolation between keyspaces. We could then configure infra-related things such as sharding and replication at the keyspace level. The big downside to this idea is that it’s a pretty hefty change to the current structure. It would either come with breaking changes or some mandatory migrations at the version upgrade. But we hear more and more about multi-tenancy so it could be a very clean long-term option.