As noted here, this is not a hard limit but breaking it will impact performance.
I have not ever encountered a design that breaks that limit (thank God!), but I would assume severe performance degradation just approaching it. I didn't even know that the limit was that high, it almost seems like an error. It's unclear why there would be different limits between lists and document libraries, as both ultimately lead to the same object (SPList) in the API.
Everything is probably much slower ranging from item form loading, rendering, list views, etc. SharePoint's object model is not optimal here in that by default it loads all metadata (i.e. all fields) when fetching items or iterating through an SPListItemCollection.
Side note, for SharePoint 2010 the limits are better described in this article. I am not aware that MOSS uses a different schema for SQL storage of Columns, but I'd guess it's not that far from SP2010.
See also here (SP2010 again) where it is noted : "Row wrapping causes a decrease in throughput of approximately 35 percent per additional row for most operations." (That is, each time you break the row-wrapping threshold for a given type). As you can see, the performance degradation is extreme.
In the same last link there is a short performance analysis. The article also states that the total size of all columns for a list cannot go beyond 8k bytes (each column's size in bytes is given). That is a hard limit, regardless of row wrapping.