Категория: суть композиции

Вы правы это было первичное назначение. Но сейчас это более общая концепция.

en.wikipedia.org/wiki/Monad_(functional_programming)#History

Нас интересует горящий пиксель или процесс его зажигания?

Читаю я ваш диалог, и мне кажется, что вас жестко дезинформируют. Нет никакого «подключить к категории». Категории — это инструмент для размышлений над задачей, а не паттерн кодирования.
Давайте, я прокомментирую точку зрения автавтора статей.
ТК — это основа системы типов в хаскелле. Тут нужно заметить, что в хаскелле система типов не как в других языках, тут она не только про перенос ошибок на время компиляции, но и про общую корректность программы, так что используется она на полную катушку. Именно поэтому паттерны программирования в хаскелле тесно связаны с системой типов, и чтобы думать о задачах согласованно с принятыми в хаскелле паттернами полезно знать ТК.
Вы можете возразить, мол это все про хаскелль, при чем тут я? Оказывается, что хаскеллевый подход потрясающе решает ряд задач, которые не под силу ООП и другим стилям: например, композиция примитивов concurrency. При этом понятно, что дело не в хаскелле, а в паттернах и в их основе — ТК, так что ее знание полезно каждому программисту, а не только функциональщикам.

1) Чистая — да, это без эффектов.
Но смысл ОС как раз в управлении эффектами
Если быть точным, то смысл ОС — управление доступами и ресурсами.

Давайте я попытаюсь аллегориями пояснить.
Ваши высказывания по ОС подобны — «ноль не может быть числом, это же нет числа».
Я парирую — «ноль — это обычное число».
Вы — «но ведь суть нуля — в том, что нету числа!»
Тем не менее, попытаюсь сказать, что всё же «ноль — это обычное число, ибо с нулём можно делать всё, что и с числом. Если что-то крякает как утка и плавает как утка — это и есть утка».

ОС с точки зрения чистой функциональщины — это монада состояний, потому что ОС подчиняется законам монад состояний.
Если утка плавает как поплавок, и всплывает как поплавок, утка и есть поплавок.
Это никак не противоречит, что ОС — управление эффектами.
Это изоморфные понятия, или говоря проще — что в лоб, что по лбу.

5) Категории — это филосовское понятие. Тип-классы, это то, что отражает взаимосвязи, в том числе и категории. Для упрощения, в первом приближении, можно считать, что да, одно и то же.
Если быть точным — тип-классы — это релизация ad hoc полиморфизма (смахивает на перегрузку функций).

3 + 5.a) Подключить — да, имелось в виду реализовать интерфейс.

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

Давайте я попытаюсь аллегориями пояснить.
Когда я говорю о категориях, это подобно «есть такое изобретение — целые числа, в итоге очень удобно универсально работать с натуральными и отрицательными числами как с целыми, если описать натуральные как целые и отрицательные как целые».
Или это же кодом:

-- library1.hs
data Natural = ...

-- library2.hs
data Negative = ...

-- library3.hs
class ToInteger a where
  to_int :: a -> Integer

-- library4.hs
instance ToInteger Natural where
  to_int :: Natural -> Integer
  to_int = fromNatural

-- library5.hs
instance ToInteger Negative where
  to_int :: Negative -> Integer
  to_int = multiply (-1) . fromNegative

-- app.hs
any_add :: ToInteger a => a -> a -> Integer
any_add x y = ineger_add (to_int x) (to_int y)

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

class Natural {
...
function type() {..}
function add_nat (Natural $b) { ... }
function add_neg (Negative $b) { ... }
function add_any ($b) {if ($b->type() == "Natural") return $this->add_nat($b);...}
}

class Negative {
...
function type() {..}
function add_nat (Natural $b) { ... }
function add_neg (Negative $b) { ... }
function add_any ($b) {if ($b->type() == "Natural") return $this->add_nat($b);...}
}

И если я вас совсем замучаю, то вы ещё допишите обёртку к этим двум

class Integer {
...
function type() {..}
function add_any ($b) {...}
}

Лучше станет, но не намного. Захотите рефакторить под:

trait Type {
  type () { ... } 
}

trait AddAny {
add_any($b) { ...}
}

class Natural extends Type, AddAny {
...
function type() {..}
function add_nat (Natural $b) { ... }
function add_neg (Negative $b) { ... }
function add_any ($b) {if ($b->type() == "Natural") return $this->add_nat($b);...}
}

class Negative  extends Type, AddAny {
...
function type() {..}
function add_nat (Natural $b) { ... }
function add_neg (Negative $b) { ... }
function add_any ($b) {if ($b->type() == "Natural") return $this->add_nat($b);...}
}

class Integer extends Type, AddAny {
...
function type() {..}
function add_any ($b) {...}
}

Вы не сможете, в разных библиотеках находятся, да и кода не существенно меньше.

Поэтому ответ — если нам надо написать «Войну и мир» нам всё равно придётся написать «Войну и мир». Вопрос лишь в том, что будет ли система нам помогать ставить запятые, точки. Будет ли она вместо номеров героев писать сама их имена, будет ли по ходу искаться синонимы. Будем ли мы писать как набор слов, или мы будем писать сюжетные линии отдельно, и то, где они будут пересекаться.

Неважно, будем ли мы писать текстовый редактор с помощью процедур, объектов или лямбда-вычислений, нам всё равно придётся его написать.
Но сколько и как писать код, читать код, изменять код — будет по разному.

Если посмотреть на код с числами ещё раз — видно, что подключается одно к другому совершенно независимо. В том числе и разными людьми, в том числе и менять отдельно можно.
А в связи с тем, что зависимости в большинстве случаев носят универсальный характер, ничего более допиливать не прийдётся.
Неважно, что наши данные — для текстового редактора — очень сложный объект.
Если его можно представить числом — с ним можно будет обходится как с числом, можно представить как строку — можно работать как со строкой, можно обходить — все функции по фильтрам и итерациям доступны, можно сделать функтором — тогда сможем применять чистые функции, можно представить в виде монады — сможем работать с объетом как императивщики, можно представить в виде ОбщихТиповДанных — к нашим услугам будут автоматическое подключение к реализациям интерфейсов (если, конечно, их кто-то напишет).

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

Например, есть библиотека Parsec и ей подобные, это комбинаторные парсеры, которые на выходе получают ваши данные, а не набор массивов (как в перл-образном парсере). Да и само описание парсера — просто и легко читается.
Написать на монадическом парсере компилятор/интерпретор языка программирования — очень просто (без учёта эффективности и ресурсов), так как очень просто писать правильные грамматики для них.

Можно ли всё это написать на Яве или Си? Можно.
Можно ли подобно Хаскелю писать? Можно. Именно поэтому и воруют идеи императвщиков и функциональщиков и те, и другие.
Только категории показывают как это сделать универальнее.