About an eon ago, I did some research on this topic. We needed a redistributable or widely available and inexpensive tool to allow a customer to visually design behaviors for an inspection station we knew was going to evolve over time. LabView was my first choice actually, but it was too slow on the available hardware and we would have had to write several drivers and add additional widgets which we knew from experience was an expensive proposition (I am talking mid-90's here). The solution we came up with was a righteous hack involving Visio, Excel, some VBA code and a sprinkling of stored procedures in a distributed SQL Anywhere database. But I digress...

I recall that what I found was there were ANSI, IEEE and ISO standards for graphical programming ranging from general purpose software to specialty domains such as ASIC/FPGA designs. I don't recall the numbers off hand and no longer have access to that company's internal documentation where my requirements analysis currently resides. Anyway, the OP's examples are reminiscent of some of the tools I have seen in the ASIC/FPGA arena where the aesthetic similarity to actual electronic circuit schematics was a paramount UI requirement.

A quick search turns up a couple of dozen products in the graphical programming arena. Schematic Programming isn't even covered on Wikipedia. Googling for "schematic programming" turns up some hits for schematic functional programming and this thread is high on that first page, so I would recommend that the OP should use graphical programming rather than schematic programming to describe what they are doing. Even LabView falls under the former and not the later category, btw; even if the designs are often referred to as labview schematics.

Given that virtually all of the current crop of graphical programming tools out there, including LabView, actually fall under the category of Application Specific Design Tools, I think there is plenty of room for Yet Another Visual Design Tool. Even if it doesn't get any traction, it's a good exercise to undertake, if for no better reason than to hone your HMI design skills.

The primary weakness I see in the schematic paradigm is the limited scale that it offers. Granted, you can view data-flow at varying levels of detail, but you don't have the ability to show the full range of interactions between modules. I prefer the richness of UML actually, even though I still don't have adequate tools for round-trip model <=> executable. It's a problem I would attack if I ever had the budget for a dozen or so person years of effort.