I figure I should get around to adding my 2 cents:
First off, I admittedly have made little use of circuits. I mainly have used them to regulate oil cracking (and I'm sure many other players have). I am aware of how to do quite a bit of more advanced stuff with them, but most of that stuff isn't practically useful to me (I do just fine controlling my factory designs with mechanical back-pressure, so I see little use for circuits in my games so far).
That being said, there are things I would like to do with the circuit network, that I haven't yet because they are either not possible, or else so complex to implement that it doesn't feel worth the hassle to even try, and that right there is I think where the OP and I would be in agreement: The circuit network can't do things it aught be able to do, and even quite a bit of the things it can do are disappointingly complex and/or intuitive to actually implement.
By way of examples, to help give the devs so suggestions on where to take things, here are some things I've wanted to do, why I haven't done them, and what perhaps could be added/changed that would remedy the problem, as I see it:
-Making a display to track how much of something is in storage: This is, in some sense, currently done automatically by the logistics system, but of course, this only works for items actually in the system's storage and passive provider chests. The problem isn't so much getting the count: that's easy with a few wires, it's displaying that number in a way where the player can see it 'at a glance'. Now this has been done, but creating displays is complicated and rather tedious (I did figure out how to make one with help from the forums, including from XKnight himself). The resulting display is also quite large (each lamp takes up 1 building square, so to get decently readable numbers, that's probably at least 5x3 per number; quite big actually). The solution to this is fairly simple imo: add displays as a buildable entity that are much more compact. There are already some nice ones in mods out there for the game, this is an example of something from a mod that imo ought be implemented in the vanilla game.
-Creating a system to dispatch trains to pickup ore (or pickup/deliver other items) only when there is a full load stored at the mine: The problem with this one isn't controlling the train itself so much as the fact that you don't gain any benefit over a mechanical back-pressure system because trains have set schedules, hence you still need at least 1 train per mine (or else having the train stop at multiple stations, which introduces its own set of headaches and ofc the train pathing is less efficient than the ideal dispatch system would be). Perhaps there is a way of doing this that I haven't thought of, but then the issue imo would be that it's quite unintuitive how to achieve the desired setup: some number of (small) mines, all served by 1 train which is dispatched to whichever mine has enough to fill the train (so as long as total mine output doesn't exceed train throughput, no backups), gets filled there, then comes and delivers back to base, (one could even have multiple trains and a 'waiting' area for trains ready for dispatch). Being able to set a train's next destination via circuit connected to the train stop would be a very useful feature (there would obvious have to be some consideration given to implementation, for instance, one would want the train to only visit that stop once typically, then continue with the rest of it's scheduled round, or similar) and would straightforwardly solve this problem.
-Another thing I've wanted to make, but haven't dared attempt: A smart assembly block. That is, a Requestor chest connected to some inserters and other chests and a Furnace, Chemical plant, and Assembly machine 3. Which be controlled by the circuit network so that: I could make a request for some number of some item to be made, it would automatically calculate raw materials needed (up to oil derivatives for fluids), and then deliver the raw materials to the chest (and fluids to storage tanks), after which it would assemble the materials into components and those into further components until it at last made the desired item. I haven't made this in part because I would expect it to be complicated to begin with, but it would be nightmarishly so with the current state of combinators, not to mention the myriad of potential problems a system like that can have in the present state of the game, plus the daunting (but understandably needed) task of hand wiring all the logic and manually programming all the (relevant) recipes. I wouldn't expect a project like that to be simple to do: it's exactly the sort of thing I would expect to appeal to a circuit enthusiast and the sort of problem that makes me wanna dive deep into learning the ins and outs of the circuit, but even the masters here on the boards have struggled with similar smart factory designs and most of them report that their designs have the potential to be messed up easily by a host of possible unforeseen causes (the inserter stack size problem is just the latest in a long history of such issues). The big problem with this in vanilla atm is that you can't set assembler recipes by circuit network, and there is a fairly understandable reason why: Where should the unused ingredients in the assembler go? I don't have an easy answer here, but I think something should be thought up to address this is a logical, usable way because the ability to set recipes opens a ton of doors for useful circuit contraptions (and something new to optimize: how to make everything you need on as few assemblers as possible).
This is by no means a census of things I've longed to do but haven't due to complexity, size, lack of robustness of the system, lack of features necessary to do it, and so on. Speaking to more macro level question of what to do about the circuit situation in a general sense, I think the main problem is that the circuit network is kind of like coding in Assembly, people hardly ever do that nowadays because it's too low level for most of what software engineers are trying to make. Much easier and more efficient to code it in C++ or Python or whatever. If the circuit network was remade in a way where many of the basic things you'd want to do with it were built into the functionality of the most basic components, then it would be both much more accessible, and perhaps even, more powerful than the current implementation (it'd certainly have way less design headaches!).
As an example of what I mean by higher-level functionality, consider the following prospective changes:
-All 3 current combinators merged into a single device called 'Combinator' (current tech level) with 3 modes of operation: compare, compute, constant. Would serve the function of all current combinator types with a single device, just the set the mode based on what you want it to do and voila, the rest works as it does now.
-New device called State machine (intermediate tech): It would have a configurable number of states (up to some reasonably small limit, maybe 5 or 10) as well as conditions for state change, and outputs associated with each state. The inputs would be used to trigger the state changes from one state to another. Vastly simplifies the creation of finite automata and other state-based systems.
-New device called Processor (more advanced tech): maybe 3x3 in size or so, more wire connection points than combinators and state machines, has an internal grid (maybe 10x10 or 20x20) similar to modular armor within which you could place State machines and combinators, configure them, and wire them to one another, and the Processor's connection points accessible in this menu from the edge of the aforementioned grid. The point being to allow for more complex systems to be made (relatively) compact (one of the reasons I feel the current circuits are janky is that combinators are freaking huge for how simple a component they are (I don't mind this for early level tech, but some miniaturization later on would be nice; consider the real world equivalents are literally microscopic with current tech). This would also enable more complex circuits to be built compactly, and would make organizing larger circuit designs much easier. Not to mention the convenience of being able to blueprint Processors for specific complex tasks and then being able to replicate them automatically with logistic bots (wiring, settings and all).