With the caveat that I may be projecting or reasoning from a biased sample, I had two thoughts:
1. I think the faults you're picking on in documentation are valid, important, and also probably more organizational/management faults than TWs.
If the people who have to pay employees tend to be willing to pay developers more than they're willing to pay writers, it seems like the best "average" outcome you can expect--even if you go looking for tech writers who know how to develop--is that you get tech writers who can't or don't want to earn more money developing (i.e., they prefer writing over developing strongly enough to turn down the extra pay, don't have the skill/experience to earn more developing, and so on).
Dev/ops tools, methods, and thinking have a lot to bring to tech writing--but I can't imagine many orgs/projects can achieve this without a collaboration between developers and tech writers, or developer-writers sufficiently remunerated for possessing both skillsets.
2. Style issues in writing are much like those in programming. Code style doesn't matter a whole lot when it's a one-developer code base, but it definitely starts to matter when there are more chefs in the kitchen. When you don't nail down what the style is in either domain, everyone follows personal preference. It can work for a while, but it tends towards chaos that requires a lot more work to clean up than it would to be consistent in the first place.
Edit: This isn't to say you aren't right, but that the style issues are a sort of maintenance issue that may seem pointless from the outside but also do need to get settled (though, ideally without extended bikeshedding...)
1. I think the faults you're picking on in documentation are valid, important, and also probably more organizational/management faults than TWs.
If the people who have to pay employees tend to be willing to pay developers more than they're willing to pay writers, it seems like the best "average" outcome you can expect--even if you go looking for tech writers who know how to develop--is that you get tech writers who can't or don't want to earn more money developing (i.e., they prefer writing over developing strongly enough to turn down the extra pay, don't have the skill/experience to earn more developing, and so on).
Dev/ops tools, methods, and thinking have a lot to bring to tech writing--but I can't imagine many orgs/projects can achieve this without a collaboration between developers and tech writers, or developer-writers sufficiently remunerated for possessing both skillsets.
2. Style issues in writing are much like those in programming. Code style doesn't matter a whole lot when it's a one-developer code base, but it definitely starts to matter when there are more chefs in the kitchen. When you don't nail down what the style is in either domain, everyone follows personal preference. It can work for a while, but it tends towards chaos that requires a lot more work to clean up than it would to be consistent in the first place.
Edit: This isn't to say you aren't right, but that the style issues are a sort of maintenance issue that may seem pointless from the outside but also do need to get settled (though, ideally without extended bikeshedding...)