FWIW I’m on the “avoid” side of this, for myself (a long-time lisper) and for my students (who are often new programmers).
While I think it’s swell for others to use paredit or parinfer if they like them, some of the reasons that I don’t want them in my teaching or development editing environments are:
I often cut/paste and/or edit code in non-linear ways as I’m thinking through a problem, with my code being in syntactically invalid states at many points along the way. Paredit/parinfer makes this frustrating or impossible.
My students already know how to type and manipulate text, and requiring that they learn new ways to do this on top of everything else (basic programming concepts, functional programming, Clojure, AI, etc.) seems cruel and counterproductive. I’ve witnessed considerable exasperation stemming even from some of the less invasive “helpful” interventions in some editors, e.g. auto-typing of closing brackets, or wrapping rather than replacement of a selection when typing an open bracket. Having paredit prevent character insertions in some situations, or having parinfer add/delete brackets that may be distant from the insertion point, are much worse.
Clojure cares about brackets, not about whitespace. So it seems to me that programmers should also care primarily about brackets, not whitespace, or at least have brackets, not whitespace, foremost in their minds. Whitespace is a terrific visual guide to structure, and IMNSHO every Lisp editor must have an auto-reindentation feature that can be manually triggered by the programmer to make the whitespace conform to the programmer-typed brackets. And programmers should routinely invoke this feature on everything they write. But my preference is for the programmer to specify the brackets, and use auto-reindentation to clean up indentation and spot problems.
Again, I can see why people like paredit and parinfer, which I definitely agree are clever, and if people find them helpful then I think it’s great for them to use them. But I think there are good reasons to avoid them too, and I hope that tool developers will keep these in mind, providing ways to avoid them in their editors while nonetheless supporting auto-reindentation and bracket matching.