Упомянем понятия с "неприличными" названиями Гомоморфизм и Изяморфизм Изоморфизм. Не то чтобы они нам сильно были нужны в практике ФП, но при объяснении некоторых аспектов они упоминаются, поэтому поясним их на примере Моноидных Морфизмов.
Давайте возьмем пару наших знакомых моноидов: складывающий аккумулятор и умножающий:
Первый AddingMonoid имеет "0" в качестве пустого значения ("единичного элемента") и функцию сложения в качестве мультипликатора. Второй MultiplicatingMonoid имеет, соответственно, "1" и умножение. Легко заметить, что один легко превратить в другой с помощью школьной функции — экспоненты. Вспомним, что exp(0)=1 и exp(a+b)=exp(a)*exp(b), а значит Морфизм exp: double -> double переводит моноид сложения AddingMonoid в Моноид умножения MultiplicatingMonoid. Этот морфизм является "гомо-", т. е. таким, который переводит не только объекты категории (double в нашем случае), но и сохраняет отношения-эндоморфизмы. Проверить это не сложно: во-первых, все функции (например сравнения) сохраняют свою работоспособность. Во-вторых, мы можем применить гомоморфизм как до использования функций, так и после. В том числе мультипликатор нашего моноида:

Результат будет одинаков. Такие морфизмы и называются "гомо".
А когда в добавок есть однозначное обратное преобразование, то он будет за одно являться "изоморфизмом". В нашем случае можно воспользоваться логарифмом, который будет однозначно превращать обратно моноид умножения в моноид сложения, но у него есть одна проблема: логарифм не определен для чисел < 0. Поэтому чтобы нам получить изоморфизм с помощью exp/log, придется выбрать другую Категорию/тип: либо неотрицательные числа, либо комплексные (у которых бывает логарифм отрицательного числа, но все равно надо будет придумать что-то отдельное с нулём).
Приведем пример не-гомоморфизма на примере еще одного моноида, складывающего строки. Он у нас имеет пустую строку в качестве начального/нейтрального элемента и конкатенацию в качестве combine. Морфизм intToStr не будет являться гомоморфизмом т. к. intToStr(1) + intToStr(2) != intToStr(1+2). И уж тем более не будет изоморфизмом, т. к. нет однозначной strToInt для всех строк.

осторожно, абстракция!

SPL
Опять о сути
Монада — это контейнер. Но не данных, а контекста. Грубо говоря, монада списка содержит не элементы этого списка, а контекст его обработки в процессе исполнения программы. Она позволяет нам преобразовать поток данных (data flow) в поток исполнения (control flow) без необходимости использования промежуточного мутабельного состояния. Монада заменяет нам переменные (и локальные и глобальные), в которых мы обычно храним состояние исполнения в императивных языках.

• Монада списка заменяет нам циклы for.
  
• Maybe/Option заменяет нам проверку if (a == null)
  
• Either заменяет нам throw Exception / try ... except
  
• Reader/Writer заменяют нам работу с изменяемыми входными и выходными состояниями (которые в не-ФЯП хранят свое глобальное состояние — текущую позицию или накопленный результат)
  
• State — дает нам старое доброе stateful поведение, без необходимости создания изменяемых структур.
  
• IO — двоюродный брат State, накапливает побочные эффекты (работу с файлами, сетью и т. п.) и инкапсулирует безопасную работу с ресурсами, заменяя нам try ... finally.
  
• Future/Promise в многопоточном окружении заменяет async+await.

И все это в едином стиле с одной единственной функцией bind/flatMap и при исключении преждевременного исполнения Эффектов (т. е. "ленивость").
Про функторы
На самом деле, почти все, что дает нам монада, есть и в функторе. Давайте сравним два способа построения цепочек: функторами и монадами. Для этого у них есть методы:

Отличие только в возвращаемом типе функции-параметра. Монада ожидает, что ей вернут упакованное в нее же значение. Результат при этом будет избавлен от двойной вложенности, как было бы, если мы бы такую функцию передали Функтору:

Но зато с функтором мы можем сделать так:

Т. е. получить вложенный контекст в тех случаях, когда идет параллельная работа с несколькими контекстами. Монада с flatMap нам такой возможности не дает.
Итого, несколько утрируя, можно сказать, что монада позволяет нам накапливать контекст (без нарастания сложности), а функтор связывать разные контексты.
Comonad
Правильнее её было бы называть "со-монада" или "со-тройка", т. к. латинский префикс "co-" означает "действовать вместе", сотрудничать. Комонада (ко-тройка) — это дуальная монада. В Теории Категорий дуальными структурами называются такие, у "которых отношения поменяны на противоположные" (стрелки развернуты на 180 градусов). В нашем случае, если монада упаковывает значение в свой контекст, то ко-монада будет его распаковывать. Наша знакомая "тройка" имела: оператор упаковки, оператор преобразования и оператор связывания. Соответственно при "развороте стрелок" ко-тройка будет иметь:

• оператор распаковки extract/coreturn (вместо pure/return).
  
• оператор связывания с запаковкой coflatMap/duplicate

Оператор преобразования map не меняется, т. к. по обе стороны "стрелки" у нее одна и та же знакомая Категория.
С распаковкой extract все просто: эта функция извлекает значение из контекста монады. Не из каждой монады можно извлечь значение. Например, из монады "список" нельзя извлечь значение, если список пустой. Поэтому комонаду можно получить только из класса "НеПустойСписок". При этом извлекать значение можно по-разному: например, всегда первый элемент или всегда последний. То есть Комонада — это довольно специализированная хрень, под конкретную задачу, аналогично Моноиду.
"Оператор связывания с запаковкой" может пригодиться, когда нам надо связать два моноидальных контекста (контейнера) с помощью функции, которая при обработка возвращает распакованный результат F[A]->B. Таким образом, в алгоритмах комонада непосредственно не нужна, но при составлении программы из функциональных конструкций, может оказаться полезной чтобы избежать ненужных (рас/пере)упаковок, там, где не надо.
Аналогично существуют кофункторы Cofunctor и комоноиды Comonoid (крайне редко используемые в виду уж излишней экзотичности).
Bifunctor/Bimonad
Бифунктор — это функтор для 2 параметров. Используется для работы с монадами кайнда (отсылаю к прошлой статье за пояснением про кайнды) * -> * -> *, т. е. по-нашему это функция bimap (аналогичная по смыслу map), принимающая 2 параметра, для обработки монад с двумя параметрическими типами. Например, Either[E,R] может содержать ошибку E или результат R и неплохо бы уметь преобразовывать каждую из них независимо в нашей цепочке вычислений (data-flow). Для этого и пригодится бифунктор.
Бимонада (Bimonad) — это монада, построенная вокруг бифунктора…… могли подумать вы и сразу бы ошиблись (ха, получи фашист гранату!). Потому что Bimonad — это термин, введенный только в Scala Cats, где он является просто объединением тайпклассов Monad и Comonad. А в хаскеле такого тайпкласса вообще нет. Зато есть Bi.Monad, который как раз, как можно догадаться строиться вокруг бифунктора.
Laws
Законы в ФП — это формальные ограничения, накладываемые на реализацию тайп-классов. У каждого тайпкласса свой набор законов, и он всегда явно прописывается словами/тестами в документации этого тайпкласса.
Это чем-то похоже на контрактное программирование. Гарантируя соблюдение этих правил, вы позволяете использовать эти свойства в других классах/типах/библиотеках и быть уверенным, что они корректно вернут результат всегда, для любого Моноида/Монады/Функтора, независимо от их природы.
Иными словами, если вы объявили, например, свой Моноид, то будьте добры сделать его в том числе ассоциативным ((a+b)+c ==a+(b+c)). Если ваш Моноид не соответствует этим правилам, то это не моноид, а хрень какая-то. Передавая такой псевдо-моноид библиотечной функции (которая, опираясь на законы, имеет право оптимизировать вычисления как пожелает) вы уже не можете надеяться на корректный результат на выходе (получите аналог unspecified behavior в C++).
Referential transparency
Раз уж вспомнили про теоретические нюансы, то надо упомянуть ссылочную прозрачность.
Ссылочная прозрачность (в противоположность ссылочной мутностинепрозрачности — referential opacity) — еще один запутанный термин с простой идеей: чистая функция, не производящая никаких эффектов, возвращающая при одинаковых параметрах одинаковый результат. В таком случае говорят, что ее вызов можно заменить на взятие готового значения. Например, из кэша (словаря из пар "входные параметры -> результат"). Повторный вызов таких функций по идее не нужен, производить вычисления чистых функций можно производить параллельно, что может быть использовано компилятором/оптимизатором. Всё ФП работает с чистыми функциями, изолируя недетерминированные Эффекты в отдельном "гетто", о чем мы говорили в первой статье.
Происхождение самого термина несколько запутанно. Придумали математики, адаптировали философы, а в программирование термин просочился без какой-либо видимой целесообразности примерно в 1960-х годах.
Transformers
Трансформеры — еще один "привет" от мастеров naming things в ФЯП. Трансформеры ничего никуда не трансформируют. Они оборачивают. Они врапперы (wrappers) — они оборачивают одну монаду в другую и дают набор методов для работы с внутренностями вложенной монады. Слишком сложно объясняю? Давайте проще. Вот есть у вас отложенное (асинхронное) вычисление опционального значения id = Future[Option[Int]] (некий асинхронный обработчик вернет вам число или None). Это может быть, например, id-ка из которой мы захотите залукапить (lookup) объект. В функциональном, чистом от эффектов, мире вы не станете извлекать айдишку из этих контейнеров раньше срока (т. к. оба слоя несут важный контекст: 1. отложенность, 2. опциональность), а воспользуетесь функцией map/flatMap чтобы из Int получить свой объект. А раз у вас тут 2 уровня вложенности, поэтому придется написать flatMap 2 раза:
id.flatMap(idOption => idOption.flatMap(idInt => DataBase.lookup(idInt))).
Ленивые ФЯП-программисты придумали сделать трансформеры-врапперы, которые могут вам упростить жизнь в таких случаях, просто построив объект-монаду сразу из двух монад. Т.е. в данном случае с помощью трансформера FutureT[Option, Int] (здесь "T" означает transformer, как не сложно догадаться) мы можем получить монаду, которая будет вести себя как "плоский" контейнер, для которого можно будет избежать лишнего вложенного тривиального flatMap'а, оставив только лямбду с лукапом: idT.flatMap(idInt => DataBase.lookup(idInt)).
Таким образом трансформеры — это по большей части такой "синтаксический сахар". Главное, ради чего все это затевается — это то, что весь необходимый контекст каждого слоя останется во внутренностях трансформера(ов) и при необходимости может быть оттуда извлечён.
Если в функциональном угаре вы получите три или больше уровня вложенности (от которых по какой-то причине вы не хотите избавиться), то можете засовывать трансформеры друг в друга, пока не надоест. Правда есть одно "но"...
"Monads do not compose"
В переводе на понятный эта фраза означает, что даже если есть монады M1[A] и M2[A], то их композиция M1[M2[A]] не всегда будет являться монадой ("монадичность не транзитивна").
А значит, что для некоторых комбинаций трансформеры невозможны.