Here's an example...

Let's say you are writing an application that presents a bill. That bill should not change over time and it's attributes won't be queried on for aggregation or any other ad hoc reporting scenario, because those queries will go to source data. However, you'll want to store a snap shot of that bill to be able to reproduce it later when the account holder requests it on the web site.

A table that stores those snap shots might have an primary key identity column and maybe an owner column to allow getting that one bill but the bill itself may be stored as a UDT in a single column to simplify access and leave the data structure interpretation to the application. It could contain all the info that normally is in the bill, perhaps an image, and may even include an electronic signature, etc. to ensure that the bill's values haven't been changed.

Certainly simple bills could easily be stored as an old fashioned row, but complicated bills with detail records, special rate plans, etc. might be better stored this way rather than with many tables that have been normalized and maintain referentially integrity through constraints.