There is no way in efking hell I would try a schematic where components are not connected with lines. What is wrong with you people?
It is distressingly common.
My conjecture, without evidence, is that people with a software background dabbling with hardware transpose software habits into the hardware domain. Software design tools (IDEs) easily navigate text-only designs, and hardware design tools don't prevent it.
You definitely have something there, regarding my own habits (when using EasyEda online schematic and PCB editor).
When designing a circuit, I don't care about the placement of the tracks, and net labels make them invisible and thus reduce my cognitive load. I do like to try and keep each modular unit fully connected –– any group of components that perform a specific task, that I can replace with something else, when refactoring the schematic or minimizing the BOM cost –– and find OP's schematic scattering into individual separate ICs extremely confusing, too. If a module does not fit, just use larger sheet. (At least EasyEda and KiCad support this; I don't see why any schematic editor wouldn't.)
For example, in this design I have the three connectors on the left, the power supply (and supply enable) stuff at top, PWM level shifting circuitry at bottom center, and tachometer level shifting on the right. This way I can think of each one in isolation, and this helps me manage things. (I know the schematic could be better, too.)
It is much easier for me to read this kind of a grouped/modular schematic, than one where everything is connected via visible wires.
I think that is fine.
Separating independent sections is natural, and becomes a requirement in a large diagram, one section per sheet. The PSU is a classic example of that.
Each of your sections has an independent "signal flow", so there is no need to mentally insert the connections. By contrast the OP splits out
tiny sub sub sections which
obscures the signal flow, leaving reader to wonder what the signal flow is: where does it start, where does it end, and have I spotted
all the connections.
A connector that has a large number of logically unrelated signals is a classic pain point. The way to think about it is to consider a reader starting at the connector, and trying to work out which bit of the circuit deals with each signal. It is normal to have large connectors shown as a single component, with labelled wires coming out.
In good schematics there will be an annotation indicating "the other end" of the wire. Sometimes that will be "to Sheet5 Q1" (and the other end of the wire reverse labelled "to Sheet1 Conn6". Other times there will be a "top level" schematic showing all interconnections between subcircuits, a bit like the main() function in a C program.
(And I still occasionally mix a bus with a single wire with lots of branches. So, I do expect this to change if I work with schematics enough.)
Again, that's fine - provided each wire is named where it enters/exits the bus. All the reader has to do is follow the bus to find out all the connections. Classic examples are address busses, data busses, and control busses (R/W, CS, etc).
When I switch to PCB design, I use the ratsnest option (that shows which pads/wires need to be connected together with directly connected visual lines and highlights), so I don't need to think about routing at the schematic design phase. This really helps me get things going, step by step.
Again, that's perfectly standard.
Sometimes it is known when creating the schematic that certain PCB rules will have to be followed, e.g, differential pair matched length or impedance control. With simple tool for small designs, those constraints can be simple text annotations. In complex tools for big designs where a different person does the PCB layout, such properties can be entered into the schematic, and the tool will (hopefully) ensure the PCB layout person has complied.
In the cases where, say, several signals are individually buffered before going off-board (e.g. a control bus with inverters), the schematic designer will wire them up without knowing the detailed PCB layout. That may cause an unnecessarily tangled set of wires, and it is perfectly reasonable for the PCB person to swap pins. Such swaps are then
automatically back-annotated into the schematic.
I suspect that people like myself with software backgrounds probably find this modularity easier than fully connected schematics, simply because they don't have the experience to quickly comprehend and mentally modularize fully connected schematics.
There I disagree. "Coupling and cohesion" are the same in hardware and software. The question is how to think about and denote that.
Analogies are always dangerous, but consider each small subsection being a function. It would be ridiculous to have multiple source files and to scatter each function across the different files. It makes much more sense to gather related functions into, say, a (singleton) class with each class being in a separate file.
I do assume/believe that those with lots of EE schematic capture experience do that kind of modularization without thinking about it or even realizing they do it, because when I look at DiodeGoneWild or BigClive explaining their reverse-engineered schematics, their grouping of the components and parts follow mine; and when a component has multiple purposes, it tends to throw them off too (as such multipurpose components do not fit cleanly into a modular model of the circuit).
Reverse engineering is, arguably, irrelevant. When you are creating a design and schematic, that is forward engineering.
Your examples are more like someone looking at machine code and trying to work out what's happening. That's a very different task with very different objectives.
I'm just explaining the reasons I have for doing it that way, and how I believe my reasons doing it that way relate to both hobbyists with software backgrounds, and those with proper experience in schematic capture. The only thing I ask is forgiveness for not having the skills yet to do it right, as my skills are still barely enough to get it done this crude way. Suggestions for improvement are gold, but seeing the deficiencies said to be "distressing" is alarming. I definitely agree that having inputs on the left, outputs on the right, makes it easier for me to understand even the modular schematics with lots of net labels; as does having positive voltages above and ground and negative voltages below. I'm just not skilled enough yet to achieve all those desired goals! (So I assume neither are the other myriad hobbyists.) In the meantime, I do still show my scribblings, although I want to point out that their crudity and my willingness/hopefulness in receiving criticism and learn from my mistakes is why they're all in Public Domain / CC0-1.0.
All just fine and understandable.
Techniques that aren't a problem with small designs, don't scale to large designs. That's why you can't use BASIC for large programs.
Fundamentally it is a matter of understandability and good taste. An engineer ought to be able to comprehend the former, but the latter cannot be taught!