Плохо использовать пренебрежительные названия, особенно когда дядька даёт дельный совет, ю ноу. Автор на S.O. имеет в виду, что нужно разделять понятия entry point и application. Т.е., должна быть входная точка, а должно быть и приложение. Отдельно. Плюс такого подхода в том, что лучше соблюдается SRP, а также приложение можно использовать в других входных точках "более чисто": будь то Android или GWT (но это зависит от крутости понимания и реализации ООП), или обычные юнит-тесты. Класс Application можно считать фасадом с точки зрения шаблонов проектирования. JavaFx здесь ни при чём.

----

Заметки на полях

В учебниках стараются писать максимально простой код, чтобы упростить понимание и закрепление материала. Поэтому main(String... args) в таких случаях встречается почти везде.

morethancoding.com/2013/08/20/understanding-softwa...

Не нарушает, так как не является составляющей, которая определяет "правила" ООП. Под множественным наследованием, привносящим проблемы, скорее следует понимать наследование классов, то есть, готового поведения и состояния. С наследованием интерфейсов проблемы как таковой на уровне реализации интерфейсов нет, но может в некоторых случаях быть неприятной в JVM-языках, когда реализуемые интерфейсы декларируют методы с одинаковыми именами, но методы семантически разные. Это чисто техническая проблема. В то же время, в среде .NET, насколько я помню, этой проблемы нет. Класс, реализующий несколько интерфейсов -- вполне обычная и хорошо зарекомендовавшая себя практика (например, стандартная библиотека виджетов GWT; "наблюдаемые" коллекции в .NET и пр.)

Не имеет значения, на каком языке сравнивать агрегацию и композицию. Две концепции являются отношением has-a, то есть технически реализуются одинаково: например, класс или отдельный экземпляр класса (если у прототипа объекта нет такого свойства) ссылаются с помощью полей на экземпляры другого класса (хотя и не обязательно другого). Отличие состоит в том, что в случае композиции один класс сильнее зависит от другого явно заданного класса и, по большому счёту, не может без него существовать.

Вот пара ссылок:

* sergeyteplyakov.blogspot.com/2012/12/vs-vs.html
* programmers.stackexchange.com/questions/61376/aggr...

Также обратите внимание на то, что в случае композиции, класс/объект сам определяет связи и время жизни этих связей -- то есть, полностью владеет им.