Those are useful general-purpose libraries. Treat them like any other library with its own specialized terminology - and, like any other library, don't use them until you need them.

I think a big problem is that it's hard to slowly develop "taste" in Haskell. That is, it's hard to navigate the path from not knowing what you do and don't need to use to accomplish your task, to being able to tastefully choose the right tools. Like you say, things like lenses are just useful libraries that you may or may not need, but how do you know? People on message boards and blogs may suggest that they are the right way to solve your problem, and you have to grok a bunch of stuff to determine whether or not you agree.

I find this harder in Haskell than other languages, because I find it harder to progress slowly. In most languages, step one for a beginner is to just hack something together, maybe even using direct for or while loops, switch statements, and the like. Then you can go back and figure out what the language gives you to express what you've done in a better way. Then you can iterate on that basic process, moving up the levels of abstraction, often finding at various points that you didn't need to write any of the code you wrote because a library exists that does the same thing if you call it in the right way. By the time you're reading about the library, you understand the contours of the problem it solves, because you've already done a worse job of solving those problems yourself. I've always had trouble injecting myself into the right point of this step-wise procedure in Haskell, and instead feeling like I need to do a bunch of research on the right ways to do things in order to make any forward progress.

I think the issue is that the frameworks in Haskell expose the generic abstractions they're built on, whereas in another language a similar framework would just offer opaque magic. E.g. when writing a web endpoint you can see that you're returning something that uses a monad transformer and you can easily dive into the details of what that means and what the framework functions that manipulate that are actually doing: in the long run you will eventually want to do that, but in the short run "the framework will call your function with these parameters, by magic, and customizing that behaviour requires you to change things in the framework's internals" can actually be easier to get started with, since it tells you clearly which parts you should be messing with and which you shouldn't.

I don't have a good answer, because I wouldn't want to stop building Haskell frameworks that way. But I do agree it's a problem.

Sounds reasonable.

The way people talk about them often feels to me like they are language constructs.

They're not, but they're general-purpose enough that you end up using them in a similar way. When you have higher-kinded types it becomes possible to write very general libraries that are applicable to a lot of different problems. This is great because it means you can reuse the same libraries you're used to in a very different domain, but it can make it harder to learn them because they're not about anything specific.

I think there's definitely a haskel trend to prefer "accurate" nomenclature vs merely "serviceable correct". That is to prefer "joint rod and spherical cap digging implement" vs "shovel".