It's not about convincing, but about improving the rate limiting system. The actual load is roughly equivalent whether you send 1 sub with many filters or 10 subs with less filters in 1 conn or 10 conns etc - you need that data, you will request it one way or another. Rate limiting at sub/conn level is just a dumb way to evaluate and limit the load that client is creating. Better rate limiting would take into account the actual number of indexes touched or table scans performed or filter conditions matched for incoming events and events retrieved and served on per-IP basis, then number of filters/subs/conns wouldn't matter.

Could you please publish an example list of subs that you'd like to have persistently active, so that we could have some rough idea of the potential load it could create? Also for pre-sync state and after-sync state - the sync load probably differs greatly from the "watch-for-updates" state?

It's been painful to build the current (pretty dumb) event sync for npub.pro, so I agree things need to be improved in this area.