This answer has two parts:
First, for maximum performance and scalability, to retrieve the lists you should be using web.Lists[Guid]. Iterating through web.Lists and picking your selected lists, or using web.Lists[Name] (which also iterates through the set internally) will causes the API to retrieve metadata for all SPList objects under that SPWeb, which can potentially be a huge.
That means you would be using a List to collect them, since you cannot create a SPListCollection except from web.Lists or similar calls (SPListCollection has no public constructor, so you cannot do 'new SPListCollection' and build your own).
Second, if you get down to the basics you should really be careful building a List< SPList >. In many cases, manipulating a SPList object on its own will cause the API to access its parent SPWeb (for example, by using SPList.GetItems(SPQuery)). If you have already disposed of it, you might incur perfomance hits. You should keep your manipulations of SPList close to the scope of its parent SPWeb object, and implement proper (not related to SP* objects) interfaces and/or repositories if you want to expose SPList or SPWeb data outside their scope. I would avoid List< SPList > entirely in most cases.
Side note on the difference between SPListCollection and List< SPList >:
SPListCollection is, as are most collections in SharePoint's API, based on SPBaseCollection. That class is implementing ICollection (non-generic) instead of the new, much more feature-full and extensible generic ICollection(Of T). You could transform a SPListCollection into a List< SPList> (or better, ICollection< SPList>), but that would violate the best practice given above.