It really does depend on how you’re intending to use that data and where…
Remember, whenever you load a thing from the database, ALL fields are loaded.
So if you have a thing with a list field of 100 things, that field alone will load 100 unique IDs (3300 characters of data).
Now, that’s no big deal at all…
But if you’re loading a list of those things (in a RG for example), maybe 50 or 100 things, each of which has 100 things on a list field, well now that’s 10,000 unique IDs (330,000 characters of data) being loaded to the page (just from that field), which is going to be costly in WU and performance.
So, you see, it’s really not a simple question, and there’s no one-size-fits-all answer.
As I said, the best way (in both WU and Performance) depends entirely on the many intricate specifics of your app, the amount of data involved, the size of the data involved, and how often it’s being loaded.
In my own testing, storing lists on a satellite datatype is by far the best way to handle lists of several hundred things.
By 2000 things, that’s no longer true.
I haven’t yet established at what point between a few hundred and 2000 the change occurs (but that’s in my own testing - a different app might get different results, for all the reasons mentioned above).
So, aside from gaining as much understanding of performance and WU as you can, I’d recommend doing your own testing in your own apps to see what works best in your specific circumstance.