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

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

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

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

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

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

Для постоянного ношения думаю очень пригодится натянутая сетка при спине (не знаю как эта технология точно называется). Например как здесь www.deutergb.co.uk/products/all/bike/all_bike/deuter_trans_alpine_25/21/
Гораздо комфортнее носить, спинка рюкзака получается жесткой и отделена от спины пространством. Но вместимость весьма страдает от этого, и из-за изгиба спинки ноут не удобно упаковывается.

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

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

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

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

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

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

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

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