It's much more of a one way conversation, if you can't imagine all the rotations to make a part do something, trial and error is very slow.
Whereas in GUI CAD you mostly only have to be able to think in 2D.
And without a constraint solver, you have to have a much deeper understanding of all the spatial relationships involved.
Your object is not something that can then be used to iterate on, except by placing it in space and adding or subtracting other stuff to/from it.
Have you looked at Build123D or CadQuery?
Both are Python packages (different API styles, compatible underpinnings) that do OpenSCAD-type things, but using the OpenCASCADE bRep kernel, so it is less "counterfeit" -- if you want to do something based on a face or edge or vertex that was the product of a previous operation, you can. Both have some constraints support.
In many ways they are both just a prettier alternative to the FreeCAD Python APIs -- indeed there was a CadQuery workbench for CadQuery 1.x.
It's like the BASH of 3D, if I'm doing anything with code CAD, it's probably trivial enough that just using what everyone else uses makes sense, even if almost any other alternative is much nicer.
This is a little bit of why I jumped to FreeCAD from OpenSCAD -- the existence of prebuilt distributions of FreeCAD, and the realisation that I'd always be able to script FreeCAD if I needed it.
Though I think Build123D has the beginnings of momentum (I also think it's not hard to see why):
https://github.com/phillipthelen/awesome-build123d
But OpenSCAD is a terrible, obstinate "standard" choice; I wish it were not seen that way, don't you? Because it's holding everyone back.
(This does make me realise that maybe working on an Electron-based Replicad desktop app would be a good use of my time.)
But the difference is relatively small, because I'd rather be using GUIs for anything nontrivial.