I don't know how many is too many, but I've run into publishing issues when a service was going to have over 60 layers in it (it was a weird project, don't ask!).
As far as "separate services" vs "layers in a single service", it really depends on what you're going to use them for. "Layers in a service" makes sense for some things, especially as you can make use of the $datastore Arcade variable and access other layers in the service, whether or not they are present in the map / app. It might also make sense to keep certain thematically related datasets together.
For example, we maintain a layer of voting precincts as polygons, and a layer of polling places as points. These layers are pretty much never used separately, so putting them into the same service makes sense.
On the other hand, if your layers are going to change or be republished a lot, you may want them separated. There are certain things you can do to a layer (creating hosted feature layer views, map image layers, etc) that can lock the source layer for schema edits, and you may not want that to impact half a dozen different layers.
Also, though you didn't ask about this, if you're looking to "refresh" your AGOL layers using an authoritative source regularly, I would look into ways of accomplishing this that do not involve overwriting the service. Frequent overwrites can lead to the source layer breaking sometimes. Unless your service is changing the number / types of layers in it, or making drastic changes to the schema, there's no reason to overwrite. Try a standard truncate / append process instead, using the ArcGIS Python API.
- Josh Carlson
Kendall County GIS