Это потому, что все сообщения ЖЖ падают в одну таблицу. За секунды могут добавляться и удаляться десятки и сотни сообщений другим пользователям.
Если бы для каждого юзверя была отдельная таблица сообщений, то они шли бы по порядку.

Из этой общей таблицы они растягиваются по журналам и лентам через идентификатор журнала (пользователя) ЖЖ к которому относится сообщение.

Когда-то в бытность свою системным архитектором сочинил архив для интернет-портала немаленькой корпорации, в котором в качестве хранилища использовалась одна таблица из трех колонок для произвольной конструкции портала и разнородной информации (в т.ч. видео, картинки, звуки).

Я как будто так и думал, что есть некая бщая таблица, но понимания это не добавляло, потому что, допустим, у только что зарегистрированного журнала id были бы тоже астрономические.
То есть моя логика говорит мне, что журнал А зарегистрирован (условно) 1 января 2002 года и созданная в нем 16 декабря 2004 года запись имеет номер (допустим) 5619854.
Журнал Б зарегистрирован 16 декабря 2004 года и первая запись в нем, созданная сразу после упоминавшейся записи в журнале А, должна быть тоже тогда иметь номер 5619855.
Но эта самая первая запись в журнале Б имеет id, допустим 256.
Очевидно, моя логика как-то не совпадает с логикой БД. Вот я и заинтересовался: в чем? :)

таблиц конечно побольше
навскидку по внешнему виду можно назвать:

-таблица пользователей (журналов)
-таблица сообщений (возможно что разбита на две таблицы - корневых сообщении и обсуждений)
-таблица друзей
-таблица событий (календарей)
-таблицы групп друзей
Ну и конечно всяческие вспомогательные таблички - коллекции картинок, смайликов и т.д.

Все они связываются друг с другом через идентификаторы.
К примеру. Все записи всех журналов хранятся в таблице сообщений и у каждой есть ее идентификатор, но для каждой записи еще хранится идентификатор пользователя, журналу которого эти сообщения "принадлежат".
Что значит "связываются друг с другом"? Их связывает между собой механизм базы данных при получении запроса типа "А дайте-ка мне содержимое журнала такого-то пользователя, или дайте-ка мне список френдов этого пользователя". База данных обрабатывая такой запрос связывает в нужном порядке необходимые фрагменты содержимого нескольких таблиц и выдает требуемый результат.

Как между собой соотносятся разнородные таблицы, я примерно понимаю (я пытался в свое время "влезть" в основы технологии OLAP). Единственное, чего я не понимаю, это почему идентификаторы записей в одном журнале не идут подряд и не начинаются с единицы. Наверное, будь я менее ленив, сам бы все освоил, благо коды ЖЖ выложены в открытый доступ (http://www.livejournal.com/doc/server/ljp.dbschema.ref.html)

Это просто.
Каждая новая запись в любом (!!!) из журналов "забивает" новый (следующий по счету) идентификатор в таблице записей (сообщений). В эту таблицу пишут разные пользователи. Потому оно идет с большими интервалами. В промежуток времени между двумя вашими записями разные люди успевают настрочить несколько сотен.
Кроме того возможно идентификаторы удаленных записей могут использоваться для вновь создаваемых (есть такой прием). В этом случае после 3000 кода Вы можете вдруг получить 1200 а затем - 3305.
Так что на эти самые идентификаторы обращать внимания всерьез не стоит.
Кроме того все что я написал - всего лишь предположение. Это наиболее простой классический вариант использования, "логический костяк" можно сказать. Если на него навешивать всяческие дополнительные требования связанные с оптимизацией базы, повышением ее устойчивости, защищенности, балансирования нагрузки и т.д., то там вообще может быть черт те что. :-)