Смысл в том, что открывается возможность выполнять преобразования данных на стороне сервера без предварительной выборки. Например, можно быстро отфильтровать записи, с отметками времени, относящимися к определенному дню недели (за все время), произвести агрегацию данных в других полях и вернуть результат одной записью. С датой в unixtime в поле integer пришлось бы или вытаскивать полностью всю таблицу на клиент и там считать, или писать огромный велосипед на хранимых процедурах на сервере (и все равно это будет медленнее, чем встроенные функции, у которых предусмотрена даже оптимизация при поиске по индексу).
С географическими координатами все еще интереснее. Как вы себе представляете задачу поиска/выборки всех, объектов в заданном радиусе от заданной точки, если координаты в таблице заданны широтой и долготой в полях integer? На плоской поверхности это еще относительно легко (все равно фильтрация пойдет в два этапа (с подзапросом, например), и на первом этапе будет выбираться много лишнего, так как целочисленные индексы не могут на лету фильтровать по вычисляемым выражениям). А что если радиус поиска/фильтрации измеряется сотнями и тысячами километров? Засада тут в том, что Земля то не плоская ... А для географических координат (как специальный тип данных) для этого существует специальная функция, в которой все это уже предусмотрено и решено, а еще под этот тип данных существует специальный тип индекса, позволяющий производить поиск и фильтрацию с меньшей вычислительной сложностью (то есть намного быстрее), чем по двум индексированным полям integer.
