Хочу сразу все сделать правильно
Все хотят, да вот ни у кого не получается ;)

стоит ли тогда заморачиваться с выбором базы данных?
Разумеется, хранить надо в отдельной базе данных, можно и файловой. А то когда захочется шаблон html-ки поменять, будет не смешно.

Казалось бы, что может быть проще и легковеснее, чем отдавать статичные .html файлы
Собственно, ничего, поэтому для незалогиненых пользователей, которые генерируют 90% трафика, стоит использовать именно статичные .html файлы. Запросы пользователей, которым надо генерить индивидуальные странички, надо направлять на движок в обход кеша (например, по факту наличия соотв сесионной куки).

Где лучше хранить кэш с .html документами?
в соотв. documentroot, чтобы nginx мог их легко найти и отдать, прямо по запрашиваемому урлу. Крайне желательно поддерживать некоторую вложенность папок, чтобы в каждой папке было максимум несколько тысяч файлов или других папок.

Или может все хранить в тех же файлах?
Все нельзя. Только то что редко обновляется и долго остается валидным. Для короткоживущих данных лучше использовать все-таки memcached, во избежание лишней нагрузки на диск. Либо FS в памяти, если уж хочется работы с файлами. Для короткоживущих данных в php есть замечательное средство кеширования — pecl модуль APC (основное его предназначение opcode cacher, но данные он тоже может кешировать)

У работы с файловым кешем свои тонкости. Например, данные в нем менять надо атомарно, т.е. через временный файл и последующий rename(). Также желательно использовать блокировки чтобы избежать ситуации, когда несколько запросов паралельно начинают генерировать один и тот же элемент кеша. Часто нет необходимости немедленно перегенерировать элемент кеша при обновлении данных, достаточно его удалить, а генерация произойдет при запросе.

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

Я бы на Вашем месте создал бы тестовую табличку и сделал бы бенчмарк, заодно по результатам можно и статью на хабр отписать, многим было бы интересно.

Также нетривиален вопрос выбора движка хранения, у innodb будет очень заметным оверхед по месту для хидеров строк, если структура таблицы очень простая и размер строки небольшой.

Надо тестить, в общем…

Вообще-то толстый кабель это как раз гут, он более надежный и сопротивление меньше. Аудиофилы так те вообще считают, что меньше 2 мм квадратных площади в сечении на проводник нельзя и близко к аудиотехнике подносить…

А вот длину лишнюю убрать не помешает.

В принципе, наверное лучшим вариантом будет поискать не сильно дорогой аудиокабель для bi-wiring с сечением порядка 1мм на проводник — в нем будет 4 жилы, и надо чтобы можно было разделить две пары жил, т.к. у Вас наушники с раздельным подводом кабеля.

Любой, после перепрошивки dd-wrt, например.

Не примите за занудство, но bash (и другие sh) не умеет заходить на ftp. Вам необходимо использовать внешнюю программу, которая это умеет, и тут начинаются зависимости от версии Вашей ОС, что установлено и что можно установить и т.д. и т.п. Уточните вопрос.

btw, если есть возможность логина по ssh вместо ftp, то вопрос решается легко через
find /path/to/dir -type f | wc -l
Всяко производительней делать подсчет на стороне где лежат эти файлы, вместо пересылки списка файлов. Кроме того, команда dir протокола ftp не делает рекурсивный листинг, так что таких команд придется прогнать столько, сколько найдется поддиректорий, это дополнительные тормоза.