There is only one real benefit, yet its huge:
Separation of Concerns.
So, instead of process orchestration logic being embedded in our system, it becomes and external configuration. A map, basicly. You can change it (much more) independently, you can have multiple processes, multiple versions of processes, multiple versions of multiple processes running at the same time, and that's all out of the box in any decent solution.
Historically, the concept of SoC have won many times - starting from the Unix principle "do one thing, but do it good", and being applied again and again - like having dedicated server components like ESB, different persistance systems, caching, load balancing, monitoring, like splitting CSS from HTML, etc.
Your business process and its flow rules are often orthogonal to your data, UI "screens" or users "hierarchy". So, it makes perfect sense to develop and change it separately from the other aspects of the system. That was the premise on which BPM has appeared in early 1990s.
Since then, many of tools and languages were created to support this concept, with most well known being BPMN - a graphical language for creating "flowcharts" that directly map to processes. While people complain that its large and unwieldy (having over 100 symbols in vocabulary), and advocating modern approaches like S-BPM (has only 5 base symbols), current industry practice is to stick to BPMN or its derivatives, subsets or siblings.
You do not look pleased with BPMN:
Programmers here appear to be doing a significant amount of work in the lines and boxes layer, which to me just looks like a really crappy, really basic visual programming language.
But its not that bad ) There is theory behind it. And version 2.0 took some good insight from 1.0 shortcomings.
If you're going to go that far, why not just use some sort of scripting language?
Imperative paradigm and scripting languages are not always the best answer. As you've probably seen in declarative languages (like HTML, CSS, SQL, Drools or internal ones of Nginx, Graddle and Maven, Puppet etc) the resulting code can be much smaller and cleaner, than a version written in "decent language, like Java or C++".
As for your other point:
as far as I can tell, are visual programming languages at this point, complete with conditionals and loops.
have you looked into the Events and Triggers ? BPMN is a language and you have to learn it before using, or at least get familiar with it.
Under the hood, BPMN is XML, so you can edit it by hand, or generate. And you can version control them, because XML is text-based. However, just having an XML that can be translated into flowcharts, does not sound like its goona help you, and that's correct - writing your own parser or editor for it is a tough and expensive task with questionable benefits.
Luckily, there are already tools at the market which do exaclty that.
Activiti is free, and quite popular among both developers and busines owners, because of its initial price (zero), availability of information and humbleness. The last point is really unique, as Activi only focuses on managing your business processes, without trying to tie you in with whole-package solutions. Also, its open - so you only need to know Java and REST to get it up and running. The drawback is that client side, integration and application/businesss logic and the whole architecture are left to developer, so if your develpment team is weak - prepare for the fail. Total cost of ownership can be surprisingly high for a free tool ;)
Good side of it ? you can implement complex system WITHIN WEEKS [PDF, see page 22]. And yes, result is not guaranteed.
IBM have somewhat recently (accoring to the enterprise time pace) have bought Lombardi, and is now offering very competitive solution (but then you will have to buy everything ibm, you'know). Appian is young vendor who has interesting insights and positive feedback, but the way they are written (two extra DSL languages in addition to visual one) just doesn't appeal to me.
There are other players, and their solutions. Most of them are plain horrible. Like - your eyes, brain and heart would literally bleed, when you simply look at them. So, trust your guts and don't make your developers and user hate you.
BPM system is the same for for processes, what Photoshop is for images. Don't be afraid that its visual. Don't make it do the job not suited for it (remember web sites created entirely in Photoshop, which were next to impossible to edit?). Keep it simple and don't make bugs ;)