Am I the only one who ignores all 'best practice' findings from SAST tools?

I’ve been conducting a comparative benchmark of the major SAST platforms (Coverity, SonarQube, Snyk Code, Semgrep) for integration into our Kubernetes-based CI pipelines. A consistent pattern has emerged that I’d like to validate with the community: I find myself systematically suppressing or outright ignoring a specific category of findings, which the vendors universally label as “best practices” or “code quality.”

These are not vulnerabilities or clear security flaws (e.g., SQL injection, hardcoded secrets). They are recommendations like “cognitive complexity too high,” “function has too many lines,” “use early returns to reduce nesting,” or “replace this `if` chain with a `switch`.” While I understand the intent—maintainable code can be more secure—I’ve observed that these rules generate overwhelming noise with questionable security ROI.

My primary issue is one of signal-to-noise ratio and resource allocation. Consider our pipeline’s performance characteristics:
- A full scan of our primary monorepo (~2M LOC) takes ~45 minutes on 8 vCPUs.
- In the last scan, **~62%** of the total findings (1,847 out of 2,978) were categorized as “best practice.”
- Triage time per finding (for a senior engineer) averages 90 seconds.

This translates to roughly **46 engineer-hours** spent reviewing items that, in our assessment, have never directly prevented or even indicated a security incident. This is a significant opportunity cost, pulling focus from the ~1,131 findings categorized as “security” (of which, admittedly, only ~15% were true positives).

Furthermore, these “best practice” rules often conflict with team-specific patterns or performance optimizations. For example:

```java
// Flagged: "Method 'processBatch' is too long (120 lines)."
// But refactoring this particular batch processor into smaller functions
// would break the hot loop, increase context passing, and measurably impact throughput.
public void processBatch(List batch) {
// ... complex but optimized logic ...
}
```

My current approach is to disable all non-security rulesets in our production security gate. The “best practice” scans are run separately, with findings sent to a dedicated dashboard for optional team review during sprint retrospectives, decoupling them from the security mandate.

Is this a common strategy, or am I introducing risk by decoupling code quality from security scrutiny? I’m particularly interested in data or benchmarks from other large-scale environments. Has anyone performed a longitudinal study correlating “best practice” violations with later security defects in their codebase?