Amit a cikk is említ, a jqueryvel (és egyéb, tisztán html-manipulációra használt microlibbel) az a gond, hogy ahogy nő a "szoftver"* úgy egyre nagyobb lesz a spaghetti kód.
A sok lib, tool, stb. amit megemlít az több fő kategóriába sorolható, mindegyik kategória próbál valamit megoldani. Ez nem újdonság amúgy. Ha ismered a JavaEE (vagy ugyanígy a .Net) világát, akkor találkozhattál a problémával: kapsz egy hatalmas, HATALMAS toolsetet, egy szintén hatalmas dokumentációval, és azt sem tudod, hogy mit akarsz, vagy mit kell ezek közül használni. Itt azonban rosszabb a helyzet; egyrészt az elnevezések néha teljesen randomnak tűnnek (mimózaJS, cycle.js, etc.), másrészt mivel nem egy hatalmas projekt alá tartoznak, más-más megközelítést alkalmazhatnak.
Nem megyek bele hitvitába, hogy akkor react/angular/jquery/vanilla JS alapú stackben érdemes-e 2016-ban nekiállni valaminek, inkább másik oldalról fogom meg a dolgot. Szerintem (hangsúlyozom: SZERINTEM) el kell dönteni mit akarsz: ha valami content-heavy dolgot, ahol a JS mintegy "rásegítésként" van jelen (egy táblázat populálása async módon, vagy esetleg egy commentbox bonyolultságú dolog), akkor voltaképp majdnem mindegy, mivel állsz neki, lehet az jquery is. Ha viszont egy funcionality-heavy, mondhatni: Webappon dolgozol, ott már gyakori kívánság, hogy újrafelhasználható részletek, szép szeparáció, stb. legyen. Erre jó egy framework, legyen az a "régi" idők ExtJS-e vagy az újhullám react.
*:igazából már kifejtettem az előző bekezdésben. Amíg csak apróbb szkriptekkel variálunk, nem lesz spagetti kód, mivel nincs _sok_ kód, viszont amit bonyolódik az alkalmazás, egyszercsak jó lenne nemcsak szkriptelésként, hanem szoftverfejleszésként gondolni az egészre.