1. Используем препроцессор, любой: sass, less, stylus

2. Общие стили(все что используется или может использоваться часто) в общее.
Один файл точка входа, в него импортируется другие файлы с общими стилями.
Файлы с общими стилями, максимально разбиты, по назначению, разделам... Зависит от проекта. На огромных проэктах, можно дополнительно по подпапкам разбивать. Главное что бы удобно было в этом ориентироваться.

Все общие переменные обязательно в отдельный файл*
Все общие миксины обязательно в отдельный файл*
** Дает возможность быстро изменить препроцессор, если понадобится. У всех разные синтаксис переменных и миксинов

Если миксин статичный, без параметров, лучше заменить его на класс, например .some-mixin-class
И использовать его так:
.some-class {
@extend .some-mixin-class;
...
}
При этом .some-mixin-class нельзя использовать как обычный класс напримую, только экстендить в других классах

@extend .some-mixin-class - Работает одинаково во всех препроцессорах и хорошо читается

Все общие стили только по БЕМ

3. Специфичные стили для компонента пишем в файле компонента.
Или scoped или БЕМ - как удобней
Если таких стилей очень много, то выносим в отдельный файл и импортируем в компаненте
В эти стили по необходимости(если нужно использовать) и импортируем файл с общими переменными или миксинами

Самое сложное, научится определять, что общее а что специфичное, это не объяснить. Приходит с опытом и постепенно

jsfiddle.net/zbhfrkp3/2

<span onclick="plus(this);"></span>

$(document).ready(function(){
  window.plus = (el) => {
    var cartcount =$(el).parents('.cart-count').find('input').val();
    $(el).parents('.cart-count').find('input').val(+cartcount+1);	
    $(el).parents('.cart-count').find('input').change();				
  }
})

Молодец что пишешь модульный код.
try/catch, кстати, вполне годный инструмент, если его правильно использовать.
Можно написать некий обьект или класс который этими модулями управляет, назову его Лоадер.
Этот Лоадер поочередно перебирает модули и инициализирует их(реализовать это можно по разному)
Момент инициализации модуля, оборачивается в try/catch, если при инициализации модуля возникает ошибка, Лоудер знает в каком модуле что то пошло не так и может что либо делать(высер в консоль, отправить ошибку куда либо), не запускать другие модули у которых этот модуль указан как зависимость... Любой функционал, можно в этот лоадер добавить, например измерять время инициализации каждого модуля...
Суть в том что бы try/catch - был один на весь сайт, был в Лоадере, и сами модули об этом try/catch даже не знали и не использовали.
Это при первичной инициализаци js, грубо говоря при при загрузке страницы, а по уму, основной поток выполнения(при нем любая ошибка, валит все)
А вот ошибки которые будут возникать потом в динамике, например когда пользователи нажимают кнопки или что то еще делается спустя некоторое время, уже не валят весь функционал, а только связный, то есть если это реально независимый модуль, то ошибка в нем сломает только его.

Второй способ без try catch:
Вырвать модуль из основного потока выполнения js, тогда ошибка в модуле, не будет ломать все без причин.
Есть много способов вырвать модуль из основного потока выполнения, приведу самый древний и дубовый:
setTimeout(()=>{
// здесь код модуля
}, 0)

> Как писать «отказоустойчивый» клиентский js?
- Самое главное ты уловил: "Писать модульный код", остальное мелочи