Мне кажется, какие вещи, как set,kill,$order,$query не должны выходить за предела класса данных, к которыми идет работа.
Тем более передавать такой функционал во внешние системы считаю неправильным, для того, чтобы это делать должны быть ОЧЕНЬ серьезные причины.

servitНежелание разработчиков изучать что-то новое или переучиваться или терять уже накопленный опыт в X или наличие у заказчика/исполнителя X-ов и отсутствие Y-ов могут служить достаточно вескими причинами?Причем тут нежелание переучиваться? Данные должны обрабатываться в одном месте, хотя бы потому, чтобы при изменении структуры данных не искать по всем программам, где же что поменялось. В случае Каше - это класс. Если даже если не использовать встроенную систему хранения каше, логику одной подсистемы нужно закрывать от других подсистем.
В при принципе, можно представить себе ситуацию, что класс, работающий с данными каше будет написан на PHP, но тогда он не должен существовать в Каше. Т.е. Каше будет использоваться только как М-хранилище. Нужно ли в этом случае совсем недешевое Каше?

Шваров ЕвгенийЕсть довольно много случаев использования связки Cache JDBC/ODBC + PHP. Зачем при этом люди используют платное Cache вопросы тоже возникают, но резоны находятся. Для использования глобалов и классов из PHP возможно будет больше причин?Зачем люди использую php в связке с Каше - у меня вопросов нет. Далеко ходить не нужно, у нас один из php-сайтов полностью висит на Каше, а другой в некоторых случаях подтягивает данные из Каше.
Вопрос только в инкапсуляции логики работы с данными. У нас, например, даже update и delete запрещены за пределами класса данных.

Шваров ЕвгенийНе только как хранилище - предлагается также вызывать методы классов Cache.
Против вызова методов классов и создания оберток в php для классов Каше ничего против не имею.