galithr

Я думаю вот так

Используйте интерфейс для типизации модели и используйте явное указание типа аргумента в нужном методе. Например:

<?php

interface UserInterface
{
    public function getFirstName();

    public function getLastName();

    public function getLogin();
}

/**
 * Class User
 *
 * @property string $firstName
 * @property string $lastName
 * @property string $login
 */
class User extends \yii\db\ActiveRecord implements UserInterface
{
    ...

    public function getFirstName()
    {
        return $this->firstName;
    }

    public function getLastName()
    {
        return $this->lastName;
    }

    public function getLogin()
    {
        return $this->login;
    }

}

class TestController
{
    /**
     * Здесь явно указываем тип переменной, которую ожидаем. Если мы передадим
     * объект, который не имплиментирует нужный интерфейс, то будет ошибка.
     *
     * @param UserInterface $user
     */
    public function actionTest(UserInterface $user)
    {
        $name = $user->getFirstName();
        ...
    }
}

Вам нужен интерфейс со свойствами? Определите геттеры.

Если свойства обязаны быть со значением отличным от null, то можно просто проверять на !== nullкаждое свойство.

Сделайте метод, который проверяет эти свойства

Есть стандартное решение. UserSearch model унаследованная от модели User и ActiveRecord соответственно. Что у Вас за модель унаследованная от \yii\base\Model? Дайте код хотя бы. Не понятно с чем мы сравниваем?
Но если вообщем, то не вижу причин не использовать стандартные методы, которые можно сгенерить через gii.

Чем стандартная реализация не угодила? Которая генерится через gii или есть в шаблонах.

Всегда называла в единственном числе. При генерации связей понятно, какого типа связь.
Например, пользователь пишет заметки.
Сравните.
$note->user;

$note->users;

В первом случае гораздо очевиднее, что у заметки один автор, а во втором может показаться, что несколько авторов, хотя это не так.

Официальную рекомендацию не могу найти, но тут yiiframework.ru/doc/blog/ru/prototype.scaffold названия моделей в единственном числе.

В единственном числе.

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

Я использовал временные таблицы, когда нужно было получить большое количество данных и отсечь ненужные в зависимости от разных условий, с массивами и прочим такое не сделаешь, а вот занести во временную таблицу, сделать выборку - это уже очень удобно.

adminunix.ru/create-temporary-table-mysql-sozdat-v...

Самый простой путь.

Сводная таблица по записям.
Триггеры на добавление, обновление и удаление.

Сперва делаете JOIN и скидываете всё в эту таблицу.
А далее триггерами она будет обновляться и изменяться.

Создавать под каждый отчет таблицу с нужными колонками и наполнять, периодически дропать эти таблички

где правильнее по MVC реализовать функции работы с АПИ - в модели или контроллере?

Работа с API - это работа с хранилищем. Точно так же как и в случае с базами данных. Потому это деталь реализации модели.

Контроллеры должны быть тонкими и содержать только то что оносится к HTTP. Модель (и все что под ней) не знают ничего о HTTP.

Ни в первом ни во втором. Это отдельный сервис загрузки данных о пользователях. В MVC его впиховать не стоит. Вызывать его из контроллера - это ок.