The examples of "tech stuff" you mentioned are very junior programming tasks. The "programming" the article talks about is all the non-PM/BA stuff: the overall technical design of the system, not just the file writing and database queries; the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc.
> I can get the tech stuff done. Of course, I'd like to do it myself, but I can get others smarter than me [...] to do the tech stuff.
Project managers and business analysts usually try to add technical skills to their resume by dabbling in some of the "tech stuff" of the projects they're managing. Usually this is the highest level stuff like architecture design or programming language selection or programmer analysis/selection: generally the stuff with the greatest impact on the success or failure of a project. You write "Of course, I'd like to do it myself" so I guess you're one of them. But those with PM/BA experience are the least able to do this project-critical tech stuff.
Project Managers get to dabble in this work because of their power in an organisation. They also try to keep their jobs by "creating" work and problems, just like middlemen everywhere. They stop technical people gaining too much power by splitting the systems into arbitrary projects. They give programming jobs to their mates in return for loyalty.
Despite their talk about being accountable for their results, in reality they cover their behinds in case they fail. When the tech stuff goes wrong, they leave behind a huge mess for programmers to clean up, usually with extra hours and overnight standbies. The business users get to do unit testing as part of their change acceptance process. The PM's go into recruitment and back into management somewhere else. A recruiter once told me "if I had a job like that on my books, I'd apply for it myself".
