Software developers and project leads are paid to ship product, even if its held together by glue and duct tape.
The problem is they don't have security and risk reduction in their incentives and automation, and they should, call it DevSecOps or whatever. After all, availability is one of the areas of security, but that usually falls on operations.
Software has distinct functional requirements for which you can test in a concrete way, either at a technical level, within a business, or in a competitive way in the marketplace. It's therefore possible to know what's "good" or "not" and in many cases to know who is a "good software engineer" or not.
Cybersecurity isn't like that. It's often hard to tell valuable cybersecurity practices from useless ones, because it's almost impossible to test them, and the practice of defense-in-depth means that useless activities are often piled on top of useful ones.
The target for cybersecurity should be "just good enough", but there's no feedback because "just good enough" has the same outcome as "pointless vendor quackery cargo cult review hell" for the objective function.
Just good enough is also a question of risk appetite. If the business decides it wants to "accept the risk" rather than take whatever measures necessary to remediate a risk, that's up to them.
Cybersecurity organizations usually have no idea what "just good enough" is, for the reasons I stated. So you end up with commercially impractical security requirements, and then vigorous sucking of teeth and requests for "compensating controls" (usually: do something equally impractical) and then demands that the business "accept the risk".
I've worked with a bunch of people in "compliance" professions (like line 2 compliance teams in banks, operational risk teams) but this attitude is significantly more common in cybersecurity than in other cases.
Just good enough often times is an orgs own policies and standards, and security teams catch when things aren't meeting those standards.
Your complaints are a lack of maturity in your cyber security organizations. There are cases where a business can absolutely decide its "good enough". But that decision is made by people other than those that point out the vulnerability. It's usually done by which ever team handles security remediation or they talk to someone who handles that analysis as part of the remediation process if the fix seems prohibitive. Cost to fix can also go down as new solutions become available or infrastructure changes and a new design makes it easier to build in a fix/control/detection or whatever. So re-evaluating "accepted risks" periodically to see if its something that's easier to implement is also part of it.
Cybersecurity shouldn't be in the business of saying no (unless its something insane like storing passwords in plain text on open shares), we're here to say, "here's some problems we see", here's where we think we can help, everything else is up to the frameworks and policies your company has set to adhere to or someone at a higher level to say cost exceeds risk, we accept the risk until such point cost comes down, etc. Cyber should also be helping to put in systematic controls that make good controls the default, and good practices easy to implement, so that ops and devs don't have to think about it.
In fairness, lots of the quackery cargo cult stuff often comes from outside the security team, and security is just tasked with enforcing it (e.g. it comes from contractual requirements with customers or other compliance stuff)
There's a dedicated department that already does that in most organizations -- risk management.
One could argue that 'cybersecurity' ought to be a component of 'risk management' versus being on its own which only adds to bloated organization structure and increases bureaucratic complexity.
... her.