The big advantage of changing the storage mechanism from row-based to column-based is that queries over large amounts of mostly-static data go much faster and take up much less space. MySQL, Postgres, and Oracle are all more or less row-based - each row or set of rows is stored whole - while in a column-based store, each column is stored individually, and the rows are held together in some fashion.
Say you have a lot of columns and few tables, and that all your normal queries heavily use a few columns - if you're doing marketing maybe that's zip code and age range, or if you're doing inventory prediction maybe it's item id and sales date. Pre-sort those columns. If you want to get addresses or sales records of everyone in a certain zip code of a certain age - say, the 20-somethings that bought at the local Wal-Mart - that's now very quick, because you can sort a table first on the zip code column, then on the age column, and then on whatever else. It's like addressing an array, as opposed to processing each row and testing a few columns.
That's not a big win on your PHP/MySQL website, but that's a huge win in your 10TB data warehouse.
Once you sort, you can do really simple compression like run-length encoding to get the size down. Maybe you have a million people per zip code, but if you've sorted on zip code, you only need to say "entries 1 through 1 million in the zip code column have value XXXXX". You don't get as good compression on the column used for the next-most-important sort, but it could still be pretty good.
Vertica also does some cool things with replication and redundancy.
Is column-oriented revolutionary? C-Store has been out for a few years, and there are a few commercial and free software implementations out there, and it's in the textbooks, so no.