The -maxconnections setting primarily controls how many inbound connections a peer can accept. The number of outbound ones is independently limited (~10), so unless -maxconnections is set lower than 10, it doesn't affect outbound connections.
My mental model is that inbound connections are primarily a service you provide to the network. As your node cannot control who connects to you (apart from evicting "bad" connections when the limit of connections gets exceeded), quality of inbound connections isn't guaranteed. Certainly they may be helpful too, but in adversarial settings we cannot assume that. Thus, we generally assume outbound connections are "better" (though quantifying this is very hard).
So I believe the answer to your question of "what should I set -maxconnections" to is simply as much as you can tolerate, but there are few benefits to you personally.
Let me go into some aspects that this setting impacts:
- (+) eclipse/partition resistance: More connections does mean that you're more likely to have at least one honest connection to the network, but with the caveat that due to the limited control we have over inbound connections, outbounds are far better to accomplish that. Of course, connectable slots are a (sometimes) scarce resource too, which restricts how many outbound connections is reasonable to have nodes make.
- (-) (average) bandwidth There is a bandwidth impact from having more connections (something that Erlay aims to partially address), primarily because every transaction will be announced at least once over every connection (~36 bytes per transaction), in one of the two directions. On average this adds maybe ~1 KiB/s per connection in an honest steady-state situation (block-only connections have a lower impact).
- (-) block propagation latency More connections means more nodes you'll announce newly discovered blocks too; if they all fetch those at the same time, your network connection may get saturated to the point where it increases the latency of your connections.
- (-) memory usage This is probably the most important impact a connection has in common situations. The various buffers and data structures used to keep connection state can (especially in adversarial conditions) amount to several megabytes. There are certainly systems running Bitcoin nodes that couldn't tolerate thousands of times that.
- (-) CPU usage I don't really have hard numbers for this, but I expect that the CPU impact of an additional connection is relatively low. After all, you won't see meaningfully more blocks or transactions with more connections, as even with a single (honest) one you're expected to see ~all of them. There is cost on the P2P side of things too (just shuffling messages around, checksumming them, decrypting them in case of BIP324). And in adverserial situations, an attacker can probably saturate the Bitcoin Core network thread with just a few connections anyway.
There is a project to increase the default number of inbound connection slots in Bitcoin Core if they're blocks-only connections (which have lower bandwidth/memory costs), with a prospect to increase the default outbound connection limit later.
