Окей, подождём gencho. Я всё-таки не делаю книги, мне просто было любопытно попробовать.

То, о чём мы говорим — удобство, завершённость и прочее — имеют смысл только в приложении к некой цели. Пока мы её не определим, разговор будет абстрактным, потому что эстетику к делу не пришьёшь, да и у каждого своё понимание, что есть красиво.

Поэтому наверное можно выстроить такую последовательность:
1. Книга в бумажном виде. Свои плюсы и минусы, свои цели, перечислять не буду.

2. Архивное хранение, когда нужно избежать потерь. Сканы в TIFF и прочих «точных» форматах. JPEG, и уж тем более вейвлеты тут использовать очевидно нельзя. Цели архивного хранения могут быть разными, и они будут определять в первую очередь качество и разрешение сканирования.

3. Быстренько переслать другу статью/рисунок/рукопись/книжку, сохранить себе. Обычные JPG, когда не надо заморачиваться, а просто сканернуть.

4. Быстренько сохранить/переслать статью/рисунок/рукопись/книжку чуть более продвинуто и удобно для хранения/чтения/каталогизации — завернуть в один файл. Это DjVu без текстового слоя, может быть с метаданными. Можно использовать и PDF, но хранить голые картинки в нём имхо извращение. Как я успел заметить, в основном именно такие сравнения между этими двумя форматами и показывают ошеломляющее преимущество DjVu, что неудивительно. :)

На этом заканчиваются чисто графические способы хранения и начинаются танцы. Если с графикой в плане вывода всё было понятно (альфа и омега: разрешение + потери, ни о каком изменении документа для удобств вывода, кроме масштабирования, речи нет), то дальше появляются варианты.

Промежуточные:
5. Быстренько распознать статью/книжку и переслать текстовый файл. Плюсы — легко ознакомиться, минусы — из рассмотрения выпадают формулы, рукописи, графики.

6. Быстренько сохранить/переслать статью/рисунок/рукопись/книжку «с удобствами», объединив со сканами (опять же быстренько) текст без особой вычитки методом «как получится». Текст можно добавить в виде отдельного «сопроводительного» файла. А можно вклеить его в текстовый слой в DjVu или в PDF, поверх скана страницы. Очевидно, что главное приложение, я бы сказал, бытовое.
Плюсы: чтение (с большого экрана), поиск по тексту.
Минусы: возможности по адаптации к устройствам вывода по-прежнему ограничены масштабированием, что не всегда айс. Особенно если мы говорим о ебуках и мобильных устройствах. Также у нас появляется некоторая избыточность: большое количество текста присутствует и в графике, и в собственно текстовом виде. Причём графика нужна только в ограниченном количестве мест. На это можно возразить, что мол потери по объёму невелики, но не такой ли аргумент оспаривали на djvu-soft.narod.ru? Мне кажется, нужно быть последовательным: если уж мы ратуем за сокращение объёма (спорный тезис, но популярный среди апологетов DjVu), следует признать, что оно в DjVu происходит вовсе не всегда оптимальным образом. Причём не по причине нерадивости кодирующих, а в силу принципиальных особенностей формата. Для любого схожего набора алгоритмов, текст + графика будет занимать больше объёма, чем просто текст.
Таким образом, в качестве основных преимуществ здесь я бы выделил не «рекордно малый объём», а скорость создания того, что можно прочитать с большого экрана и проиндексировать. А при необходимости, и обработать на следующем уровне.
Кстати, на этом же этапе можно добавить и интерактивность, и гиперссылки.

7. Уже не так быстро: вручную (или автоматически, или полуавтоматически) разделить текст и графику. Текст рассматривать только как текст, всё остальное — как растр. На самом деле трудозатраты во многих случаях не катастрофические, хотя в качестве полемического аргумента всегда можно найти книжку, где графика и формулы доминируют. :)
Плюсы очевидны: у нас впервые за всю историю процесса появляется возможность для reflow — мы можем в определённых пределах менять взаиморасположение элементов. Я уже не раз писал, для чего это не просто нужно, а критично: в первую голову для компактных устройств отображения. При этом мы сохраняем все формулы и картинки в первозданном виде (предел качества определяется разрешением сканирования). Я специально подчёркиваю этот момент, потому что похоже существует заблуждение, что только полностраничная копия спасёт сложные формулы. Это не так: достаточно перевести в растр только формулы. Более того, мы можем выбирать, сохранять формулы/картинки с потерями, или без — для архивирования.
На этом этапе мы уже уходим из домена DjVu — как я понимаю, формат не поддерживает «гнездовую вёрстку» со сложным взаиморасположением графических, векторных и текстовых элементов. И не поддерживает сохранение отдельных графических элементов без потерь. Не будем сейчас обсуждать их значимость для архивирования.
Хочу заметить, что на этом этапе у нас есть в распоряжении не только PDF, но и банальный и простой в использовании HTML, и CHM. С интерактивностью, гиперссылками и прочими радостями.
Преимущества: reflow и огромный мир мобильных устройств, сохранение всех преимуществ с предыдущих этапов (есть формулы, возможно индексирование, всё в одном файле). Возможность скопировать не только текст, но и отдельные картинки (иногда полезно).
Недостатки: больше трудозатрат, это раз. Рельно распространён только один формат — PDF, который отнюдь не самый удачный с точки зрения оптимизации и простоты создания, это два. Разумеется всегда можно сверстать в Кварке или в Индизайне, но аудитория таких форматов сразу же ассимптотически уменьшается до дизайн-контор, и про ебуки тоже можно забыть. Пара слов про «простоту создания»: на самом деле нам, как конечным пользователям, по барабану, насколько трудно пришлось программистам, лишь бы конечный результат нас удовлетворял. Можно подумать, кодирование в MPEG доступно в Notepad любому. Нет, там тоже сложные алгоритмы, но для нас важно наличие удобного софта, а не детали реализации. Для PDF такой софт присутствует в изобилии. И в формат можно печатать, как на виртуальный принтер, что безусловно плюс.

Финальные:
8. Перевод всего, что можно, в вектора. Как я понял, вы предполагаете меня сторонником именно этого способа.
Полностью векторизация невозможна даже теоретически, потому что существуют принципиально растровые элементы вроде фотографий.
Цель такого действа: максимальная гибкость в воспроизведении документа где угодно, от экрана, до типографии, с возможностью изменения содержания и взаиморасположения максимально возможного числа элементов. Это уточнение очень важно: без него мы можем просто взять TIFF в хорошем разрешении и не мучиться.
Векторно-растровых форматов много, среди них очевидно не только и не столько PDF, сколько EPS и форматы верстальных программ вроде InDesign.
Очевидные сферы применения: издательство (включая создание ебуков), переводы книг, переиздания.
Недостатки: Сложность создания. Разумеется мы говорим о reverse engeneering исходного скана — с OCR и трассировкой векторов, — а не о варианте, когда у нас и так есть все исходники.
В издательской деятельности я сталкиваюсь с этим чаще, чем может показаться на первый взгляд. Например, сейчас делается здоровая книжка про журналистику. И авторы порой шлют материалы в бумажном виде, включая и иллюстрации, и текст. Не потому, что они чайники, просто некоторые уже умерли и при всём желании не могут перенабрать текст на компьютере.

Итого.
1. Трудозатраты на 8-й этап очень велики и неадекватны большинству задач, поэтому я ратую за то, чтобы он остался только для специальных случаев.
2. Для паранойяльного архивирования нужны TIFF или аналоги. Забыли про DjVu, Jpeg и вектора.
3. Для промежуточного архивирования, когда потери не важны, годятся DjVu, Jpeg, Pdf. DjVu имхо удобнее.
3. Весь спор реально крутится вокруг того, что удобнее - 6-й или 7-й этапы. И в рамках каких форматов удобнее реализовать каждый из них. Мне кажется, я достаточно подробно обозначил их сферы применения.

Также, надеюсь, очевидны некоторые распространённые заблуждения.
Для сохранения «графика+текст» есть только DjVu. Нет, это же можно сделать в HTML, CHM, PDF, а также в изрядном количестве специфических форматов программ вёрстки. Вопрос выбора формата определяется целью. Для публикаций в Вебе имхо лучше брать HTML и PDF. Для плавающей вёрстки DjVu принципиально непригоден, а вот с PDF я слышал, есть возможность reflow (буду уточнять).
Разделение текста и графики обязательно ведёт к потерям графики. Нет, это та же самая картинка, что в DjVu. Как сосканировали, так и будет.
DjVu идеален для архивов. Опять же, it depends.
DjVu всегда меньше по размерам, чем PDF. Не обязательно. Я легко могу подобрать примеры, где это утверждение будет ложным, для любого разумного разрешения сканирования. К сожалению, много книг в DjVu, которые я видел, попадают как раз в эту категорию.
Внутренняя сложность формата PDF важна для конечного пользователя. Нет, гораздо важнее наличие удобных программ для работы.
DjVu принципиально лучший формат для электронного отображения книг. Не всегда, зависит от. Как только у нас появляется необходимость в изменении расположения элементов (все мобильные приложения, бывает нужным и на PC) — опа. Стоит рассмотреть другие форматы.
DjVu всегда легче по трудозатратам, чем другие форматы (единственным противником обычно выбирается PDF, хотя это не вполне корректно). Для FineReader нет никакой принципиальной разницы, куда пойдёт его вывод — в DjVu, в PDF, в DOC или даже обратно в TIFF. В изрядном количестве случаев FR адекватно распознаёт, где тексты, а где графика — остальное легко расставить вручную. Разумеется, как мы уже обсуждали, есть ряд книг, забитых формулами, где это утверждение неверно. Но много книг, сделанных в DjVu, в эту категорию не попадает.

btw Примеры вроде «djvu_example.pdf» — штука коварная. У djvu конечно очень хорошие алгоритмы сжатия. Но есть несколько «но». Первое: это алгоритмы сжатия с потерями. Поэтому (см. цели) если нужно архивное хранение, то всё-таки tiff. Второе: понятно, что djvu.org старается выбрать примеры, на которых она выглядит выигрышно. Я подозреваю, что Adobe может найти книги, на которых гораздо лучше и компактнее смотрится pdf. Да и сам я в процессе нашего разговора перевёл из DjVu в pdf пару книжек, получилось компактнее. Выбор материала, настроек — всё влияет.