Архитектура

[metanonum]

1. Фабрика находящаяся в index.ts нужна только для корректного подключения функционала слайдера к элементу. Валидацию данных лучше перенести в модель.
2. В чем смысл следующего слоя ferSlider? Почему в фабрике сразу не инициализировать Controller? Если есть желание выделить слой взаимодействия плагина с пользовательским кодом, то окей, но тогда нужно еще добавить механизмы подписки, которые лучше сделать через эмиттеры jquery, чтобы пользователь интуитивно понимал как подписаться на события элемента к которому подключил плагин.
3. Почему Controller выполняет что-то через модель? В рамках требуемого MVP издателями являются модель и вью, а контроллер только подписывается на их события, делегирует работу методам модели и рендерит вью по полученной от модели конфигурации. Единственное, поскольку контроллер точка пересечения событий, он может быть издателем для пользовательского кода, но тогда не событий модели, а событий слайдера интересующих внешний код.
4. Почему-то класс реализующий функционал издателя (Subject или Observable) называется наблюдатель (Observer). И, на мой взгляд, если ведется работа с именованными событиями, то лучше в качестве издателя использовать EventEmitter, это более распространенный на практике вид паттерна наблюдатель, хотя это возможно дело вкуса.
5. В чем смысл классов компонентов вью? Почему вся работа ведется во вью и не делегируется этим компонентам? (здесь также можно применять паттерн наблюдатель)

[metanonum]

9.2. Почему класс FerSlider находится во вью? Это не часть MVC.

9.4.

То что Controller использует метод this.notify - делает его наблюдаемым объектом или издателем (Observable/Subject/EventEmitter), поскольку он получает этот функционал по наследству, то должен наследоваться от соответствующего класса.
Наблюдателем (Observer) здесь является колбэк обработчика который передается издателям: модели и вью, т.к. это просто колбэк, то интерфейс Observer можно не реализовывать (обычно в нем только метод update).

9.5.

• Лучше осуществлять подписку на события компонентов, чем на конкретные элементы внутри них. Все элементы сабвью должны быть инкапсулированы внутри сабвью. Сегодня это один элемент завтра их множество, сабвью-компонент должен сам определять взаимодействие со своими dom-элементами.
  
• И сабвью не нужна вся конфигурация слайдера, каждый компонент должен получать только то что нужно непосредственно ему
  изучи Utility Types если есть сложности с трансформацией типов.

[metanonum]

Лучше не делать таких кусков.
Встроенный html-код сложно поддерживать.
Для шаблонов нужно использовать соответствующие технологии, ты уже используешь в проекте pug, это лучше сделать на нем.
Нельзя использовать БЭМ-элемент отдельно от блока.
Вместо этой вставки лучше реализовать несколько компонентов из которых строится панель и с которыми она взаимодействует.
Архитектура панели будет похожа на компоненты в токсине.
БЭМ подскажет на какие компоненты разбить кусок, из них соберется общий компонент панели и подключится к слайдеру.