Pozycja Pyramid na rynku? Zalety, wady?

Krótkie odświeżenie z frameworkami:
No 1 Django, duży, najbardziej użyteczny z SQL. Niektórzy mówią o wolnym starcie programisty (dużo wiedzy). Chwalona, sprawdzająca się w czasie architektura.
No 2 Flask. Błyskawiczny start, liczni ewangeliści (co mnie zmyliło), MOCNA krytyka od seniorów za fatalne decyzje projektowe i konwencje (skreślam)
No 3 Pyramid. W konsekwencji znacznej części serka zajętego przez Flaska, nie ma oszałamiającego udziału w rynku. Polecany przez ewangelistów Django, gdy projekt jest daleki od SQLa (dobrze zrozumiałem?)

I pytanie.
Jaki jest trzeci gracz, Pyramid, w jakich obszarach pokaże się najbardziej pozytywnie, jakie ma don't etc ?

Gdy piszesz coś co ma zarabiać, wtedy wychwalany kod, język, narzędzia ogólnie rozpraszają programistów. Na tym również polega jednocześnie urok i problem pyramida.

Django jest spoko, bo praktycznie nawet i łajza da radę coś wyklikać i na tyle obszerne, że ta sama łajza odpuści sobie próby walki z tym frameworkiem jak będzie potrzeba zrobić coś zupełnie nietypowego. Dzięki temu prace nad oprogramowaniem idą tam gdzie biznesowo ma to sens. W wielu miejscach unikamy walki, bo praktycznie z góry wiadomo, że efekt końcowy i tak będzie słaby.

Flask jest o tyle dobry, że oferuje bezpośrednie rozwiązania. Ciężko to przeinżynierować. Łajza też da radę pisać, bo w sumie odwołuje się do globalnych i jeśli zacznie komplikować sobie życie to skończy się w sumie na tym, że będzie problem z testami.

Pyramid ma większy narzut, więcej zjada czasu, a i zachęca do walki z nim, bo w zasadzie można ugrać lepsze rozwiązania. Ta walka daje owoce, ale tak jak na początku pisałem jednocześnie rozprasza i utrudnia skupić się na tym o co woła biznes.

Ja ostatnio w nowy projekcie wrzuciłem FastAPI i jestem zadowolony. Początkowo był Flask, ale chcieliśmy mieć automatyczne wsparcie dla OpenAPI/Swaggera i być trochę bardziej type-safe.