The first side is that ultimately the argument that the author debunks is a strawman argument, and the counter-arguments are equally sophomoric.
The second side is that I agree with the author on (some) of the recommendations and I think its great that the author made recommendations, instead of just pointing out perceived problems.
Cybersecurity isn't special. At least not any more special than any other subfield is in its own way. But the rest of the article doesn't follow from this axiomatic position. In fact, it's irrelevant to the meat of the article (the recommendations), and comes across to me as griping.
I think the article misses some of the realities of the business environment.
Why do (some) security teams (sometimes) try to put in roadblocks to software releases? Usually it is because the the release is going to have a business impact for which: (a) the business has not acknowledged (b) no person is accountable for (c) there are no plans for.
Why do security teams feel they must dictate outcomes rather than recommend? Usually because their leaders (running up the the Board or Executives) are holding the security team accountable for outcomes they have only indirect control over. Another common reason is that the incentive structures of various organizations push for development groups to release as quickly as possible, feature release estimates rarely include security work estimates, and teams/managers feel pressure to release anyway to avoid delaying due to missed work estimation at the project start.
Usually, these kinds of issues represent the failings of other structural aspects of the business.
Ideally security teams wouldn't be needed at all, the same as SREs and many other kinds of roles. Ostensibly developers would be so capable, so knowledgeable, so well rounded, so careful, that they would plan for, mitigate and manage all operational risks on their own.
There's depths to explore on this topic. I'm excited for the article author that they are just starting to get introduced to it. I hope they continue to explore this as they develop more seniority and experience, and share in more detailed public posts as they go along.