(EDIT: sorry for the wall of text :). TL;DR: I agree with your point, and below I elaborate on software that
can't entirely automate your work away.)
--
And I do agree! Software that can completely automate the task is the best! It's just that it's really hard. Where we could've done this, we've already done this. What remains is software dealing with tasks that cannot be fully automated[0] - tasks that require human decisions as input, decisions the software can't reasonably guess in advance.
For such software, there are two axes of interest here: how many decisions are there to be made, and how complex/consequential they are. These are inversely correlated to some degree - the big decisions (like how to repartition your hard drive or whether to sound a missile alert) tend to not be made very often[1], and they benefit from UI that trades safety for speed. My focus was the other type - the one that requires lots of individually small decisions. The type that's used repeatedly throughout the day or week.
In such software, you're guiding the computer towards a particular outcome, or a series of outcomes. The decisions involved are simple: what letters to type, when to send a message, what vertices to select, what transformation to apply, where to position items, what columns to sum, etc. The computer can't guess your goal here - often you don't know the goal yourself. You're in a feedback loop with your work, mediated through software. And it's best if that loop can be as tight as possible.
The limit to how much this loop can be tightened is the level of comfort of the user. Initially, they'll want to make every step manually. Type every letter. Click on every icon (making sure to first hover and read textual help). But soon, it gets tiring. People don't think about tasks in terms of "type 'hello<ret>'", "look where the column starts, where it ends, type '=SUM(A2:100)<ret>'". They think in terms "say 'hi'", "sum this column", "make this stuff be there". Sometimes we can predict these, we can put "smart compose" or a sum button in our software. We can add support for clipboard, autocomplete. Thus starts the "featuritis", so dreaded by modern web UX people. They're often misunderstanding the problem as having features, but the problem to solve is how to reveal the features at the right time, when the user is ready for them.
From there, there are two ways to improve still. One, ergonomics. At some point your user will be tired of having to click around to do everything. They make decisions much faster than they can input them. Software is best when it can operate at the speed of thought[2]. So why not add discoverable keyboard shortcuts? Users who reach this stage will be happy to discover they can input their decisions faster, if they don't have to hunt buttons in the UI. Their level of comfort will rise too, because they don't have to break themselves out of their flow[3]. For more advanced users still, here is where tuning enters the picture. Predefined ergonomics may be almost right, but not quite. It's nice when the user can change the defaults to better suit themselves and their particular work.
Two: composition. At some point, the user grows from thinking about each low-level decision individually to thinking about them in aggregate[4]. In a way, they DRYed up their steps into a procedure. The software thus can get better if it lets the user define this procedure somehow, and then invoke it on demand. In the limit, this means coding, but for most cases, it doesn't have to. At the very least, it means batch operations. If the user has to make the same few steps on a series of items, let them input these decisions once, and apply to the selection. This little feature can transform a work day[5]. And you can go further. Could the user save their search query? Could they combine that saved search with the batch feature? Could you turn "selecting a query and applying batch operation to it" into a higher-level batch operation[6]?
Will everyone need all such features? No. But various users will find themselves using some of them - the ones that fit well with their needs and their level of comfort. The job of UX design is then to make users more comfortable with advanced features. Making them easier to discover, test and learn, so that they can save more time. But for that to happen, the software first needs to have those features. It needs to have the room for users to grow.
--
[0] - Without human-level AI.
[1] - Except. At least when it comes to dealing with computers, a decision that's very important for your personal machine may be totally inconsequential for a cluster of VMs - so as a software author, you may want to have an "escape hatch" for batch, noninteractive work. Noninteractive work is something that comes up in all types of software, as it can let a tool gain many more use cases.
[2] - Anything less is, again, wasting user's limited time on this planet.
[3] - I realize I'm just making claims without providing any citations. I don't have any, at the moment. One of these days I'll dig into HCI literature. In the meantime, I'm just hoping everyone here both knows this from their personal experience and seen this with non-tech people at work.
A familiar example that jumps to my mind is interacting with various clerks and officials. A cashier using a good ol' keyboard-based POS system, the one that runs in DOS, can input your order and print your receipt while simultaneously holding a conversation, and be done faster than it takes you to find your wallet. Similar cashier with a modern browser-based POS system will click around screens in full focus, and have you wait a minute or three before they can update inventory. It's also interesting how stores where throughput matters - e.g. supermarkets - end up wiring their modern POS systems to keyboards.
[4] - Much like every driver has a point at which they stop thinking consciously about pedals and steering wheel and gear lever, and start thinking in terms of joining the traffic, changing lanes, overtaking - and eventually they just manifest their will through the car, while their hands and legs move themselves.
[5] - I was once asked to help some people at a sales department of a small e-commerce company to update some of their listing on an auction site. It's a job they'd be doing every couple days, taking three people an hour or two. I poked around their management panel a bit, found a very well hidden button that allows doing batch updates, and showed them how one person can do that task in 15 minutes. How much time they could've saved if that button was a little bit more discoverable?
And I'm sure that, the way it was placed, some "data whiz" at the management panel's vendor will look at the analytics, notice people don't click on this button much, conclude that users must not need it and decide to cut the feature out. The self-fulfilling prophecy of modern "data-driven" software development.
[6] - And yes, ultimately, could you let the user just write code, and also expose the functionality in CLI for headless operations? These two things will definitely be niche, but will enable completely new use cases, potentially broadening your market. How many CLI scripts already exist on Github to do a half-assed job that could be done by popular software if the vendor thought about letting it be driven headlessly by an external script?