В случае с OData не надо ничего писать для извлечения данных, если действовать как описано в статье. Yii2 дает готовый инструмент только на уровне контроллеров, при этом надо самому делать валидацию, защиту от SQL инъекций. Например, так просто нельзя ведь написать, 'weight<100'. Надо как минимум проверить, что пришедший с клиента weight это колонка, а не что-то вроде '; drop table ... --'.
POData дает готовый инструмент не только на уровне контроллеров, но и сам делает валидацию, помогает в извлечении данных. А если использовать стандартный грид с поддержкой OData (типа OpenUI5), то о том, как будет выглядеть GET запрос, можно даже не заботиться, грид сформирует запрос за вас.

Я пользовался Yii2 RESTful. Это отличный инструмент. Но столкнулся с тем, что приходится делать вещи, которые можно было бы не делать. Например, понадобилась произвольная фильтрация. В OData можно сделать условие типа такого
$filter=((weight ge 100 or weight le 10) and price le 15)
И оно будет работать без какого-либо дополнительного программирования.

Вирусдай.Сервер
Вирусбери.Клиент

Не смущает, на этот случай был придуман велосипед — переданные параметры сортируются в алфавитном порядке. В WSDL тоже параметры описаны в алфавитном порядке. Но, как оказалось, на этот случай есть готовое простое решение — вместо sequence можно использовать all в WSDL.
Некоторые ограничения на формат есть, но по практике скажу, что трудностей это не создает.

Бывает и такое. В этом случае просто JSON преобразуем в XML и направляем на валидацию

Не сказал бы, что слишком сложно. По сути, за валидацию отвечает несколько строк. Если упрощенно, то примерно так:

$validator = new \DOMDocument( '1.0', 'UTF-8' );
$validator->loadXML( $xml );
if (!$validator->schemaValidateSource($xsd)) {
  ...
}

Т.е. в PHP для этого готовые инструменты есть.
Или громоздко описания выглядят? Ну, возможно. Меня не напрягает, думаю, дело привычки.
Автоматические генераторы есть, и тут уже больше философский вопрос, что первично — документация или код. Мне близок подход, когда сперва составляется осмысленная документация.

Методы для работы с \DOMDocument, кстати, вынесены в отдельную библиотеку, или скорее даже фреймворк, его у нас соседняя команда сделала, но он к сожалению не публичный.

Фрейморк-то Yii2, но он тут ни при чем. Работа с WSDL через \DOMDocument.

Пример, входные параметры:

 <xs:element name="accountRequestData">
    <xs:complexType>
        <xs:sequence>
            <xs:annotation>
                <xs:documentation source="id" xml:lang="ru">Идентификатор записи</xs:documentation>
                <xs:documentation source="inn" xml:lang="ru">ИНН</xs:documentation>
                <xs:documentation source="is_active" xml:lang="ru">Счет активен</xs:documentation>
                <xs:documentation source="user_id" xml:lang="ru">Пользователь</xs:documentation>
            </xs:annotation>
            <xs:element name="id" type="xs:int" />
            <xs:element name="inn" type="xs:string" minOccurs="0" />
            <xs:element name="is_active" type="ns:BOOL" />
            <xs:element name="user_id" type="xs:int" />
        </xs:sequence>
    </xs:complexType>
</xs:element>

Пример части с документацией:

<operation name="methodAccount">
    <documentation type="map">
        <name>Вставка и изменение счета</name>
        <status>works</status>
        <speed_level>fast</speed_level>
        <quota_per_second>20</quota_per_second>
        <rest call="account" httpMethod="POST"/>
    </documentation>
</operation>

Именно REST

У нас на PHP проекте API описано на WSDL, это описание работает и для первичной валидации. Документацию получаем с помощью XSLT преобразования WSDL-ки. Подход хорошо себя зарекомендовал. Но приведенный в статье набор инструментов вокруг RAML впечатляет.

На мой взгляд это вполне нормально. Если закралась ошибка в самодельном исключении, то это событие тоже окажется в обработчике ошибок.
Но ваш подход тоже интересен — взять и убрать из мониторинга то, что не хочется там видеть ;) Мы может быть тоже рады были бы так сделать, но у нас так не принято.

Меняю состояние в смысле возвращаю 500 ошибку? На мой взгляд это нормально. В стандартном ErrorHandler происходит примерно то-же самое.

public function handleException($exception)
    {
        if ($exception instanceof ExitException) {
            return;
        }

        $this->exception = $exception;

        // disable error capturing to avoid recursive errors while handling exceptions
        $this->unregister();

        // set preventive HTTP status code to 500 in case error handling somehow fails and headers are sent
        // HTTP exceptions will override this value in renderException()
        if (PHP_SAPI !== 'cli') {
            http_response_code(500);
        }
...

Отлов ошибок полезен. Если случился Warning или Notice, то тоже будет не пойманной исключение. Если возникло исключение внутри фреймворка, о котором разработчик не позаботился, то такие события тоже стоит фиксировать в мониторинге. На мой взгляд, наиболее удачный подход — самостоятельно контролировать, что будет ошибкой, а что — нет. При этом все нехорошие события, о которых разработчик не позаботился, автоматически считать ошибками. Это на мой взгляд.

Мы не решаем, что посылать в ньюрелик, а что — нет.
Все, что мы делаем для ньюрелика — вызываем в index.php

if (extension_loaded('newrelic')) {
	newrelic_set_appname('projectname');
}

А дальше неперехваченные исключения сами попадают в статистику, что нас и смущало

Эта дока про вывод ошибок. Если ошибку не ловить, но аккуратно выводить через ErrorHandler, она так и остается непойманной. Соответственно, можно выбросить «GoodException», если ошибка не критичная. А если с ошибкой надо разбираться, то можно выбросить и не ловить другое исключение — HttpServerException и т.п. ErrorHandler его обработает, но оно будет непойманным.

Почему Вы считаете, что это типовая схема?

Да, та статья шикарная

Бывают не очевидные случаи. Приходит вам с клиента $POST, а там строки, а вы вполне можете думать, что там целые числа и сравниваете эти строки с числами через ==. Как вариант.