Am I wrong to think about the "graphical" aspect of visual programming languages as another layer of abstraction? If this is the case, doesn't that take some power away from these users, in the sense that their capabilities are limited to the abstractions/interface given to them by the language's developers?
Not exactly trying to question whether it's a good/bad thing (as I'm aware that for many creators this might be exactly what they need), just trying to understand.
No, because every language has one specific set of abstractions and interfaces chosen by the language's developers. This is the same for textual and visual programming languages alike.
What might well be very hard is making a language where all abstractions and interfaces map to useful graphical representations; I imagine it's much, much easier to represent a JSON object graphically than it is to represent a piece of C code this way.
For instance, how would jumps look? Lines going from far-removed boxes, producing code that literally looks like spaghetti? Moreso, do you even want to graphically represent things like pointer arithmetic, will this be easier to work with? How do you represent variables, globals?
Maybe you would only represent course features such as data flow graphically, and hide finer grained details and code in "blocks" with labels and defined in- and outputs. You would still mostly write your code, but the graphical view might help you mentally model your program.
Actually, the graphical aspect of a visual programming language is often an "un-abstraction." Text is pure abstraction with little static context beyond names. VPLs often attempt to provide more context by (a) mixing in execution context (like in Quartz Composer) and (b) through direct mappings to the domain (e.g. a VPL for layout that has you manipulating layouts directly). Much of the usability benefits, as well as scaling problems, that arise in VPLs is due to trying to them trying to be less abstract.
It doesn't have to be just another abstraction layer. In Full Metal Jacket, there's no underlying human-readable text-based language. The abstract machine it's designed to run on is highly-concurrent (MIMD) dataflow, which is very different from the von-Neumann architecture. You can represent concurrency visually better and more clearly than textually, though a few dataflow-based textual languages exist such as SISAL.
At present, FMJ is interpreted and runs on a virtual dataflow machine. This was a necessary step to ensure the computation model was implemented accurately. Compilation to run on a single processor would actually be simplified, however: there's no parsing or dataflow analysis required. Looking into the future, the question that should really be asked is whether languages designed to run on a single processor, or to execute the same instructions in parallel (SIMD), can be easily adapted to run on MIMD architectures. Do you really want to be using MPI?
Most languages compile the source to an AST, so I would say the AST is one level of abstraction below source code. Then, text and graphical languages could be equally powerful if each can represent any AST the other can.
Full Metal Jacket is general-purpose. Doing general-purpose programming in it does, however, has required me to think very differently. At present, it's still easier for me to program in Lisp, but that's mostly down to being a very experienced Lisp programmer and a rookie FMJ programmer. Initial difficulties are inevitable when you learn a new programming language different from the languages you already know. I had similar issues with Prolog but mastered that.
Different general-purpose languages are better adapted to different programming tasks, however, and Full Metal Jacket may in time find its niche. I wouldn't write a neural network in Prolog, or an expert system in C, for example.
Who do you see as the core users of these tools?