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

Во-первых, есть 2 задачи, которые решают терминальные сервера:
1. Доставка удаленного приложения до пользователя
2. Организация удалённого рабочего места для пользователя.
Эти задачи имеют разную природу. В первом случае системный администратор хочет унифицировать приложение и доставить его любому пользователю на любое устройство, даже то, которое аппаратно не поддерживает запуск бинарного файла (x86 на ARM самый частый вариант). Второе - это задача организации унифицированного рабочего места сотрудника с последующей подачей этого рабочего места на тонкий клиент, во внешний интернет на недоверенное устройство или вовсе на бездисковую станцию.

Технически в основе сессионного терминальника лежит не столько графическое API, сколько специфически затюненный под эту задачу планировщик процессов ядра ОС. Если вы пользовались терминальными службами Windows и разрабатывали под них, вы знаете что у Windows несколько планировщиков процессов. Например, при установке служб RDS происходит смена планировщика на специфическую реализацию Fair Use относительно сессий. Задачу которую решает терминальный сервер - разделить ресурсы одного сервера одновременно нескольким пользовательским сессиям так, чтобы один пользователь не повесил весь сервер. Современная реализация этого планировщика (Windows 10+) сцеплена с другими драйверами позволяет делить iops-ы на на диске и сеть.

А что если мы хотим выдать одному пользователю больше ресурсов чем второму? На сессионном терминальнике - ничего. А если у нас сессия пользователя содержит тонну фоновых процессов, части из которых нужен свой планировщик для быстрой работы? А ничего!

Я приведу примеры:
- Никакой