"whether there is something intrinsically non-value-capturing going on"
If you mean that it's hard to apply value to an individuals labour in programming you are correct, except in some rare circumstances where there is only one guy at work - then it becomes trivial.
Let's look this from the point of view of features and fixes for an individual software product.
For a car mechanic, an unserved issue means the single client may switch vendors (cost, say, 1 k).
For a software engineer, a botched feature may mean that a category of clients abandon the product (cost:1M+).
Ok, from the point of view of catastrophe recovery we know who can save more megabugs.
What about delivering value from new features? The car mechanic doesn't create anything new. Let's take the construction worker, then. This is really bad analogy but hold on.
The construction worker gets plans, builds the house, and moves on. Architecture, engineering and construction are split to separate people, all of whom have a known cost to their labour. Thus, we have a fixed project and a more or less transparent cost structure.
Software is nothing like building a house except in rare circumstances. Real world construction projects are mostly about creating linear combinations of known things.
Writing new software is like playing a combined game of sudoku and mastermind in a dark room - in the best circumstances. Sometimes the lights are on and the board is almost done, and you only need to put one piece down.
But - you can't really tell from outside what the situation is. Is the board ready? Did someone mess up the first steps and now they have to start over?
The whole thing is like a black box with input and output. The only measure of quality and value is that is the customer satisfied with the data coming out. There is no metric you can gauge the work reliably.
From the point of view of the organization the software project is like a black box, into which the team goes to do their work. They yell estimates to the project manager sitting patiently outside, who then writes project reports. After the team declares they are done, the deliverable can be tested.
You can send anyone inside the room, but only software engineers understand whats going on.
Sometimes a new programmer needs to meditate months inside the room before starting doing changes.
Sometimes the black box blows up.
Sometimes the team just goes into the box and cries all day without doing any porgress-for months - unknown to the org.
I'm sure this gets the imagination going - basically, anything that can happen with a black puzzle box and real people can happen.
I'm exaggerating to make a point, of course. But these unknowables make writing software a really risky proposition from the point of the view of the org. And individual can be incredibly productive, or a total failure, and it's really hard to point this out reliably if all are not specialists.
That's why, IMO, personal bonuses aren't really helpfull for software projects and fixed company wide bonuses are the only way reward without creating unfair situations. Any KPI based individual bonus system will at worst be destructive, and at best almost completely unfair.