Requirement 3.4 in the Payment Card Industry Data Security Standard mandates that financial service and retail companies, "render Primary Account Number (PAN), at minimum, unreadable anywhere it is stored." While the PCI standard provides a number of ways to do this, most large companies equate the term "unreadable" with encryption.
So here is the rub. PAN data is stored in a bunch of places but everyone stores it in databases. I'm talking about massive databases here--think hundreds of gigabytes to terabytes of data in many cases. Now when your database gets this big, you become very sensitive to performance and latency. Applications and databases are finely tuned and business processes and reporting is based upon extremely high transaction rates. Time is literally money.
There is an absolute technology mismatch here. Encrypting database columns is often done with stored procedures and triggers. Between these database routines and cryptographic processing, you need two things, processing horsepower and time. With applications like credit card processing, these are in very short supply. Oh sure, you can add more memory and processors to a system, but these changes don't come for free and encryption throws a monkey wrench into system tuning and capacity planning.
Something has to give here. Operating systems and databases may have to provide encryption sub-routines delegated to specific cryptographic hardware shipped on every system. Encrypted columns may need to be stored on encrypted disk drives. My point is that the industry needs to look at problems like these collectively across the "IT stack" and not just on their individual domains. If you don't believe me, ask your customers.