Yes, I think you have made the right settings, at least with the first two. The last one is just a default for your explicit subscriptions, if you have omitted the UpdateRate parameter to the SubscribeXXXX method call, otherwise it'll have no effect (and Version 5.x does not have this setting at all), and is not related to this problem.
The expected behavior with this setting is that the number of Active Tags will still increase after you Read something, but because these tags are not really active, they should not slow down the system (or, at least, not as much as before the settings were changed). And, each such Active Tag should be automatically removed after a period of time - this is the "Hold period" labeled "After topic read", and it defaults to 120000 (two minutes). There is a property for it as well, and if these inactive tags still cause a problem (and you do not expect be read again soon after the first read), you can also decrease this hold period, even significantly.
Regards,

Both are supposed to be threadsafe in the sense that confusing Item Ids as you described it should never happen - and I am not aware of such problem.
Being thread-safe, though, does not guarantee order of operations with respect to the OPC server, e.g. if two threads call two methods in sequence without waiting for the operation being completed, the actual order in which they are executed is not defined.

Yes, in every instance after creating it.

This looks like the same property in 3.0x. I think that setting it to the same thing (Infinite) or -1 will do.
Subscribing to all tags would only make matters worse.

The differences between having just one instance and having multiple instances are subtle, and should not have influence on the problem you are seeing.