Парацетамол был объективно нужен. Технически головную боль, боли в мышцах и высокую температуру можно перетерпеть. Но поспать не получится. Засыпая начинаешь стонать во сне и будишь сам себя.

В отеле пробыл 4 ночи, потом 2 в госпитале, и после 2 в отеле. Пока был в госпитале мои вещи оставались в комнате отеля.

Велосипед с батарейкой, погода хорошая, так что доехать на велосипеде было не сложно.

Т.е. на ногах переносили начало белезни

Не совсем. Я ни куда не ходил. Сначала потому что был в карантине после поездки, а потом потому что появились симптомы.

Как бы коридорчик с выходом на маленькую террасу, но из-за короны терраса была закрыта, 3 палаты и туалет/душ. В коридоре был диванчик, но им тоже нельзя было пользоваться. Можно было только в туалет и душ выходить.

В палатах возле кроватей все оборудование на стенах висит. Всякие мониторы, кислородные маски, даже ЭКГ возле каждой кровати.

Сразу как поступил капали физраствор (NaCl 0.9%) и дали 2 таблетки парацетамола.

Лечение: remdesivir капельницей 2 раза по 250мл, но флакон конкретно для меня был, с моим именем/фамилией на нем. Там были еще цифры: дозировка, частота, продолжительность, скорость...

И dexamethason. Как я понял это были 2 маленькие таблетки которые мне дали вечером и в 10 утра следующего дня.

1)

Добавлять новые зависимости просто.

При использовании Idea любую зависимость добавлять легко, так что это не аргумент.
Кроме того нет смысла что-то усложнять.

2)

… после определенного момента число аргументов конструктора становится слишком большим и тут же становится очевидно, что что-то не так.

Тем не менее это не ведет к улучшению архитектуры. Коммерческие разработчики под прессом дедлайнов тупо добавляют еще один аргумент в конструктор. Благо с Идеей это легко. Когда же разработчики берутся за рефакторинг, то они выбирают классы не по числу аргументов конструкторов, а по размеру или сложности класса. Так что и это не аргумент.

3)

Таким образом становится четко понятно, что требует класс...

Кому? DI контейнер однозначно "поймет", что требует класс (а точнее бин!) при любом объявлении зависимостей.
Разработчику зависимых бинов совершенно без разницы от чего зависит ваш бин. При написании юнит-тестов разработчику доступен исходный код класса — так что, чем меньше кода — тем лучше.

4)

… а также опциональные ли это зависимости (через сеттеры) или обязательные (конструктор)

Увы это ложь.
Например:

@Autowired public void setTest(AI ai) {} // Обязательная зависимость

Если в конфигурации не будет реализации интерфейса AI, spring выбросит UnsatisfiedDependencyException, при создании такого бина.
Чтобы получить не обязательную зависимость можно использовать, например:

@Autowired(required = false) public void setTest(AI ai) {} // Необязательна зависимость
@Autowired public void setTest(Optional<AI> ai) {} // Необязательна зависимость
@Autowired public void setTest(javax.enterprise.inject.Instance<AI> ai) {} // Разрешение зависимости под вашим контролем

5)

… вы можете создать его в юнит-тесте без запуска контейнера

Использование подходящих инструментов делает юнит тесты простыми.
Например этот тест будет работать без контейнера и при любом способе внедрения зависимостей (конструктор, поля, сеттеры, с аннотациям @Autowired, Inject или вообще без них):

@RunWith(MockitoJUnitRunner.class)
public class SmartCarTest {

    @InjectMocks
    SmartCar smartCar;

    @Mock
    AI ai;

    @Test
    public void testDecide() {
        when(ai.think()).thenReturn("42");

        String decision = smartCar.decide();

        assertEquals("The answer is: 42", decision);
    }
}

6)

Существует способ… создать объект… приведет к NullPointerException

Это опять ложь.
В рантайме спринг либо создаст объект со всеми обязательными зависимостями, либо выбросит UnsatisfiedDependencyException. CDI или другие DI контейнеры — я уверен — ведут себя также. То же самое верно и для тестов с использованием SpringRunner.
А для тестов с использованием Mockito NullPointerException не является проблемой. Это будет просто упавший тест.

7)

… нет способа кроме рефлексии предоставить ему необходимые зависимости

Для DI контейнера это не проблема. А если класс нужно использовать вне DI контейнера, то нет смысла говорить о внедрении зависимостей. Так что это не аргумент против любого из способов.

8)

… внедрение через поля не может использоваться для присвоения зависимостей final-полям

Это верно не для всех DI контейнеров.
CDI реализации в серверах Wildfly и Payara, насколько я помню, вполне комфортно внедряют такие зависимости:

class SmartCar {
    @Inject
    final AI ai = null;
}

смысл стандарта в ограничении свободы

т.е. приложение может переехать с одного сервера на другой

стандарт хоть и есть, но настолько неконкретный

ведь они не только имеют собственный способ конфигурации, но и ряд «особенностей» интерпретации стандарта.

но развитие стандартов по причине высокой формализации идут совершенно не современными темпами

javaee никак не может разобраться с тем как приложение тестировать

Может лучше было бы выпустить хорошие реализации для этих технологий

… прошло интеграционное тестирование.

I've written about this in Strict Control of Java Code Quality. I use qulice.com in Java projects and rubocop in Ruby, but there are many similar tools for nearly every language.

Если бы P была гвоздём, а C была бы завязанным в кольцо куском нитки, вытягивание какой-то части нитки прочь от гвоздя приведёт либо к вытягиванию всей нитки, либо нитка окажется накрученной несколько раз на гвоздь