IMHO but as you may see other are ok too this is more a question of the issue to solve.
You need to tell us more about your intent, it is difficult to give pro/con as there are too many factors involved to debate that in this thread.
Food for thoughts:
1 - There are various tick API because it make sense in different situation, so it depend about what you want to do with the outcome of the info.
Back to what do you want to achieve by listening to ticks.
2 - The language you use may influence your choice if performance is an issue (in Python you should give privilege to the method that lower the number of call backs or collating process)
And a warning, ticks are not precisely time stamped. You may need to implement your own stamping in the callback.
This could be a reason to prefer as it maybe that arrival time reveal a certain reality (not guaranteed as it goes trough many bucket before reaching your callback)
3- I never saw a limitation as low as 5. Where did you read this ?
Anyway no secret, if there is a limitation on one API there is the about the same limitation on the other variants, just less explicit in doc or less critical probably because people didn't use it in same condition that may reach the limits or that this API callback is slower or aggregated and you rarely reach it.
This may even give you a 'trend' about methods: the more IB talks about limitations, the faster/heavier/peculiar are the usages of it.
Also you can buy Booster Pack from IB to raise volume limitations.
