I have worked on a system which implemented a shopping cart in precisely this fashion: "in-progress" shopping carts were serialized to XML and stored into a single field in a single table in the database.
The reason to do this isn't so much performance as ease of development. I suspect that once upon a time, shopping carts were only stored in session state, so if you browsed away from the site and returned an hour later, they would be gone. I suspect that when a request came in to make them persist against a user, the quickest way to do it was just to decorate the various classes involved with XML serialization attributes, serialize, store.
The pitfall to watch for is that this will make it difficult to do much with the data other than storing and retrieving individual users' carts. For example, if a particular product is removed from the catalogue, you might want to remove it from any shopping carts. If you had your temporary carts stored as a bunch of tables you'd simply find them with something like
SELECT * FROM ShoppingCartItems WHERE ProductID=@productIdToDelete. If it's all in XML blobs, that won't be straightforward, and you may find a better approach to just re-validate all carts when they are retrieved from the DB and deserialized.