That's because it chooses a bad example of an activity for which production-line methods make sense. Pick an activity (that you need to repeat many times) where each step requires quite different tools and skills that are difficult to master, and breaking it up into tasks for individuals who specialize in said tools/skills is almost certainly going to get you better throughput. Even in the letter-stuffing example, if you imagine that if it required full/focused use with both hands of different tools for a) folding the letter b) placing it in the envelope c) sealing the envelope d) stamping it, then having different people special in and handle each subtask, even if it means paying a bit of extra time for moving the item between each individual, is likely to pay off (of course, if one of those subtasks takes vastly longer than the others, it may need 10 people doing that, vs one on the others, but that doesn't change the principle).
Obviously software development is very different - we're not asked to use the same tool repeatedly to produce the exact same result. Further, in our world a) switching between tools is usually relatively costless and b) developers are generally quite capable of becoming skilled with multiple tools.
But I'd still say that some of the same principles could apply, e.g. if those assumptions weren't true for whatever reason (e.g. switching tools means physically moving to a different piece of hardware in a different room, or there are obvious measurable differences in the skills of your developers as far as particular tools go), then splitting a task up so one part can be handled by one developer with one tool and the other by another developer with a different tool is probably going get you a better result than asking one developer to be responsible for "finishing" the whole task themselves. Arguably the important thing is that they be on the same team and consider themselves to have a shared responsibility for the task that's been split up. Which interestingly, often isn't how teams are organised in software development companies, from what I've observed over the decades. Having an end-to-end feature be the responsibility of a single team, even if it necessarily requires multiple specialists, is probably not a bad guiding principle - but on the flip side, many peoples aren't (for understandable reasons) keen on being shuffled around between teams depending on what each feature requires.
One piece flow doesn't mean the same person does everything. It could mean that multiple people do their specialty, but instead of working at their own pace with storage between them, one passes their work product directly into the hands of the next when the next one is free.
I have done the experiment with the envelopes that way too with similar results.
Obviously software development is very different - we're not asked to use the same tool repeatedly to produce the exact same result. Further, in our world a) switching between tools is usually relatively costless and b) developers are generally quite capable of becoming skilled with multiple tools.
But I'd still say that some of the same principles could apply, e.g. if those assumptions weren't true for whatever reason (e.g. switching tools means physically moving to a different piece of hardware in a different room, or there are obvious measurable differences in the skills of your developers as far as particular tools go), then splitting a task up so one part can be handled by one developer with one tool and the other by another developer with a different tool is probably going get you a better result than asking one developer to be responsible for "finishing" the whole task themselves. Arguably the important thing is that they be on the same team and consider themselves to have a shared responsibility for the task that's been split up. Which interestingly, often isn't how teams are organised in software development companies, from what I've observed over the decades. Having an end-to-end feature be the responsibility of a single team, even if it necessarily requires multiple specialists, is probably not a bad guiding principle - but on the flip side, many peoples aren't (for understandable reasons) keen on being shuffled around between teams depending on what each feature requires.