As a long-time computer programmer (I wrote the Shearson/Lehman Brothers MIS system, among other programs), some of the skills mentioned, such as when to make a component, are no different in essence than when to make a subroutine. Learning how to divide a task into subtasks is a skill that the user must develop, not something that the language or application can provide.
But, there are good applications and bad, and good interfaces and bad. I recall a product called Atmosphere, designed to do what Autocad and Sketchup do, produced by a major software house, and now more than a decade in its grave - and if it weren’t, I’d cheerfully join a mob to drive a stake through its heart and bury it at a crossroads. It sucked, for a variety of reasons.
I waded into an Autocad book more than once, and found it tough going, and unnecessarily so. Yes, I’ve known how to do mechanical drawing since junior high school, but there was a lot of tedious procedural detail, as may programming languages have. If you’re going to use it eight hours a day, the learning curve may be worthwhile, in the same way as learning irregular verbs in a foreign language may be a good idea. But that doesn’t mean that irregular verbs are a good idea, or serve to advance communication, or are anything but an antique “we’ve always done it this way” that must be learned because they’re part of the language.
I find the Sketchup interface to be intuitive, which isn’t an easy thing to do - anyone who has ever attempted to make an eight-dimensional database appear intuitive to unimaginative financial executives knows how hard it can be. The program actually works quite well, also a challenge and one that Atmosphere didn’t meet, a major reason its tombstone reads “Versions 0.1 to 1.0, RIP”.
Difficult to use doens’t mean better. Sketchup can acquire more capabilities with more ease that Autocad can acquire a more intuitive interface. If you want a command line, and sometimes I do, Sketchup’s Ruby interface allows very full control.