Во-первых, есть куча реальных приложений, когда надо вытаскивать именно N строк начиная с M, никоим образом не относящихся к вебу, например, стандартизованные печатные формы документов. Так что понимание необходимости постраничного вывода, наверное, не должно являться предметом обсуждения.

Во-вторых, всегда можно сделать что-то типа

set rowcount 10

select id_XXX
from XXX
where id_XXX > Get_id_XXX(2)
order by id_XXX

Здесь Get_id_XXX - некая (не обязательно арифметическая) зависимость первичного ключа от количества уже возвращенных записей. Собственно, сюда Вам и надо рыть, то есть, изменить постановку: возвращать не 10 записей начиная с 3-й, а возвращать 10 записей, у которых id_XXX больше, чем у 2-й.

В-третьих, цена реализации и использования top и limit может быть выше, чем даже у пары запросов через временную табличку. Это касается ВСЕХ серверов БД, а не только тех, что здесь перечислены, тех, где это реализовано или тех, где это не реализовано. Прежде всего это определяется структурой раздела order by. Так что я бы предложил наоборот, все top (верхнего уровня) и limit заменить на set rowcount и проанализировать их выполнение. Одно дело - короткий и красивый запрос, совершенно другое - как он работает в реальности.

Кстати, ощутимая часть вопросов на форуме в той или иной степени касается желания написать некий запрос без подзапросов или ряд запросов свернуть в один запрос. У меня был не один десяток ситуаций, когда деление запроса на несколько более мелких с использованием временных таблиц на порядок повышало скорость работы (только SELECT + INSERT во временные таблицы). Тем более в случае вывода результатов в веб с возможностью заказной сортировки пользователем, когда можно такой порядок в order by задать (например, через case), что top и limit окажутся просто неподъемными.