As a generic version of the answer in the question linked in the comment, you should use SeeAllData=true when the documentation for a specific feature tells you that you must use it, and you should not use it otherwise. SeeAllData has no other purpose than letting you access data that is not available during isolation testing.
It will not help you diagnose problems with your unit tests, and in fact is more likely to cause problems than it is to solve them, since production data can mess up your tests (e.g. by introduce unexpected records or values into your tests, or introducing artificial database contention).
Keep in mind that an installed package's code, particularly triggers, will still run during your unit tests, so if they're going to cause problems, they'll likely still do so with SeeAllData=false. The exception to this rule would be if you wanted to test a package's queries against a large data volume (more than 1,000,000 records) to make sure it doesn't run into selectivity exceptions, that would be a valid use case for SeeAllData=true.
The vast majority of the time, using SeeAllData=false and using sample data is the correct method to use. You should avoid writing SeeAllData=true unit tests until you identify specific objects that may fail because of large data volume exceptions, then use targeted unit tests to make sure that the installed packages will function given a large amount of data.
