Sometimes it's concretely a specific amount faster because you're replacing some other workflow with the software, but yes sometimes you're enabling something which would otherwise just not happen. Colleagues in our sister group, which doesn't have any actual software engineers, helped some academic librarians build a tool to automate something they knew they couldn't otherwise do at scale. They want to teach students how to use a library effectively, and while any of them could walk say, one student per hour through this, there are
thousands of new students every year, it's not manageable. Midway through the presentation the specialist explaining it said "It's not a program" and I was glad to find I wasn't the only person who wanted to interrupt, because duh, of course it's a program. They've built a program. It's a bunch of instructions, for how the computer does stuff, it's a program.
Yes these people wouldn't have attempted Python, let alone Rust, but what they've built is a program, in a visual programming language. Is that intimidating and so they might struggle to maintain it? Yes, a little bit maybe, but pretending it isn't a program won't help. And that might mean sometimes you need a software engineer, the same way that if we want a bike shed (and sometimes we do, students like bicycles), sometimes we might need the staff architects down the corridor from me, don't just throw up a few brick walls and hope you got it right.