My question is, how large of a list have you successfully been able to maintain in your environment? I have something that I would like to consider building in SharePoint that could potentially grow a list up to 20-30K items. I would not use the standard browser navigation to view this data, rather, a customized page in SP Designer would display a filtered view of the list (returning at max 10 items).

Good or bad idea?

Here's some supporting information from MS that has caused me to second guess this approach:

There's a white paper (as mentioned here) that talks about using extremely large lists and the associated performance issues. In a nutshell, it says the "recommended" limit for lists is 2000 items per list container. A folder is considered a container, so you could have 1990 list items and 10 folders, each folder containing another 2000 list items - which would fall within the "recommendation".

It goes on to mention that SharePoint can theoretically handle very large lists (100K+), but that the performance when viewing through the standard SharePoint browser view would be a big issue, as well as inserts & deletes. Accessing this data through means other than the standard browser (i.e., APIs, web services, etc) will improve performance, however, if it is a requirement that you go over the suggested 2000 item limit.

This does not preclude you from using lists to store large amounts of data provided that you are not dependent upon any of the XSL-based rendering methods (this includes the Data View Web Part, which makes heavy use of XSL).  The list architecture itself is quite capable of handling large datasets - we have several LOB applications that store hundreds of thousands of items in a single list; however, we search, filter, render and display those lists items in custom web parts and not with any of the built-in components. 

There are some caveats to handling large lists.  First is the dependency on custom web parts for display which I have already mentioned.  Second, and most important, handling those datasets must be done either using SPQuery methods (<= 50,000 items) or direct SQL queries to the content database (>50,000 items).  There simply is no other method for manipulating the data that does not incur heavy performance penalties.  In most cases where list items will exceed 50,000 items, we create a stand-beside database to query the content database and optimize our queries in SQL stored procedures that our business objects can translate into ADO.NET datatables for sorting and filtering.  Finally, be prepared to spend a great deal of time optimizing your search scopes to avoid indexing really large lists and, if you are using WSS, also optimizing the SQL indexing for the same purposes.

BTW, the 2,000 item per folder limit applies specifically to document libraries and is related only to rendering of objects; you can store more than 2,000 items provided you take into account the issues outlined above.