Steven,
yes we have not done a great job of documenting nor auto-tuning the reserved thread pool. The reserved thread pool was something forced onto us be the more difficult scheduling demands of HTTP2 and we didn't fully understand all the implication when it was introduced, thus we could not well document it.
However, with the next release (9.4.8) we are reaching a happier point where lazy allocation of reserved threads means a natural level is reached, plus we have a ThreadPoolBudget mechanism now to warn if a pool is over allocated. So we do need to spend more time writing these solutions.
With regards to sharing threadpools and schedulers. Yes there can be benefits of sharing these between multiple clients. There can even be benefits of using the server pools/schedulers. But there also can be contention issues if you have large machines with many CPUs. So there is no silver bullet solution that will work for all applications. I strongly advise trying some alternate configurations and benchmarking them.
cheers