The first is lines and when they merge and when they cross. Not all lines from two separate boxes to a third box ought to merge, but some should. Crossing is inevitable in most complex diagrams but expressing where the crosses ought to happen is not something I have had any success with.

The second is that some diagrams are like a story, with a beginning a middle and an end. Using horizontal, vertical and even diagonal relationships visually can be important. Keeping that story clearly organized has always been a challenge and even requires some iteration when doing the drag-n-drop thing. Rarely does the story of the diagram just happen to pop out using the default placement algorithms of any text-to-diagram tool I have used. And so I find myself tediously massaging the order of statements or whatever crude controls I'm given to painstakingly move boxes into some semblance of the story. And then, once I've managed to convince the diagram to be as close as I can to what I envision, I realize I missed a key component or connection.

The last thing I'll point out is more a preference. In general, the output tends to be quite ugly to my eye. There are times I have been responsible for generating systems diagrams for potentially big deals. In those cases we want to put the best foot forward to external entities. There is something uncanny valley, or like generated text-to-speech in the appearance of the documents that can be undesirable in many contexts.

1. the lines are not distinct -- they can bunch up and overlap, making them untraceable 2. Logical groupings are hard to maintain unless they are highly connected.