Со снапшотами, честно говоря, вживую не разбирался. Места, судя по всему, занимают немного (аналог инкрементального бэкапа). Восстанавливать, по идее, можно как весь снапшот целиком, так и отдельный файл - монтируем снапшот отдельным томом и сливаем с него все нужные нам файлы, отмонтируем снапшот. В идеале, для случая с домашним юзером, сию последовательность действий надо автоматизировать.

С контрольными суммами мешает лень и забывчивость :) Их надо вручную делать после каждого изменения файла и сверять периодически тоже вручную.
В случае же btrfs`а все файлы имеют свою CRC (точнее каждый кластер файла), которая автоматически пересчитывается при любых с ними операциях. Плюс scrub, который запускается по крону и чекает структуру диска (в том числе и CRC файлов). В случае чего, файлы либо автоматически исправляются (если у нас рейд и есть резервные исправные копии), либо, как минимум, я получаю сообщение, что файл такой-то в таком-то каталоге накрылся медным тазом (ищите бэкап). Бонус в том, что не надо разворачивать весь бэкап на надцать терабайт, достаточно вытащить из него отдельный файл, что, чаще всего, гораздо быстрее.
Да, от злоумышленника или программного бага сие не спасет (тут md5sum по-прежнему рулит), а от сбоя в оперативке/рваном шлейфе/сбойном диске очень даже поможет.

Сжатие... Зависит от того, что вам дороже - загрузка проца или загрузка винта? Иногда дешевле и быстрее прочитать 1 сектор с (относительно) медленного винта и распаковать его в 100 секторов в оперативке, чем "честно" читать всю эту сотню секторов с винта.
Кстати, btrfs поддерживает несколько достаточно быстрых алгоритмов сжатия, которые и сжимают неплохо и кушают проц умеренно. С учетом того, что ядер в процах много, то откусить процентов 10-20 от одного из них, в большинстве случаев, вполне допустимо.
А если еще вспомнить, что сжатие, при желании, отключаемо чуть ли не на уровне каждого конкретного файла, то пусть уж лучше эта фича будет...