It might be, but it's going to be case-by-case. I would be skeptical of any advice that applies a blanket policy to all use cases, at least on this topic.
To give you more examples, our main public layers (parcels, boundaries, etc), are in the shared instance pool. Those layers are referenced by dozens of maps, apps, Pro projects, and Survey123 forms in use most business days. I have never had an issue with the service itself failing to respond.
Our parcel fabric, on the other hand, is completely internal, with perhaps one or two users editing it on a given day. It actually doesn't need more than a couple of dedicated instances, and we even set the minimum to 0 because there's no impact to our stakeholders if the layers take a few extra seconds to start up initially.
What you're running into is a large number of ArcSOC.exe instances running on your server machine, one per dedicated instance. It really won't take long to max out your server that way, and it will seem like your performance is suffering. You might even consider getting more server cores licensed.
Go ahead and move a bunch of your layers to the shared instance pool and just see how performance changes (or doesn't!). If you find it's not adequate to your needs, you can easily switch it back to dedicated instances.
- Josh Carlson
Kendall County GIS