Why is Semgrep missing critical vulnerabilities in my code?

I have been conducting an extensive evaluation of Semgrep as part of our shift-left security initiative, focusing specifically on its ability to identify runtime-relevant vulnerabilities that could manifest as performance degradations or, worse, service outages under load. My initial hypothesis was that a static analysis tool of its reputation would be adept at catching patterns leading to issues like inefficient algorithms in hot paths, resource exhaustion, or insecure caching mechanisms. However, after methodical profiling against our codebase, I am encountering significant false negatives that are concerning.

The core issue appears to be Semgrep's pattern-matching approach, which, while fast, seems to lack the deep data-flow and context-awareness required to flag certain critical vulnerability patterns. I will illustrate with a concrete example from our API gateway service. Semgrep's default `java.lang.security` ruleset did not flag the following deserialization hazard, which we later identified through manual audit and which has direct latency implications (i.e., potential for excessive CPU usage during gadget chain execution).

Consider this code snippet:

```java
public class MessageProcessor {
private Object deserialize(byte[] data) {
try (ByteArrayInputStream bis = new ByteArrayInputStream(data);
ObjectInputStream ois = new ObjectInputStream(bis)) {
return ois.readObject(); // High-risk operation
} catch (Exception e) {
throw new RuntimeException(e);
}
}

public void processUserMessage(byte[] message) {
Object obj = deserialize(message);
// ... processing logic
}
}
```

A semantically-aware tool should recognize the use of `ObjectInputStream` on externally-supplied data without adequate safeguards (e.g., an `ObjectInputFilter`). Semgrep's default rules did not catch this. We attempted to write a custom rule, but the rule's simplicity failed to account for nuanced control flows or wrapper methods, leading to further gaps.

The performance and security implications are intertwined here. The vulnerabilities Semgrep is missing are precisely the ones that, when exploited, lead to:
* Catastrophic heap memory consumption, causing GC thrashing and unpredictable pause times.
* CPU saturation from arbitrary code execution within application threads, starving legitimate requests.
* Database connection pool exhaustion via crafted payloads, inducing cascading latency failures.

My configuration is not trivial; I am using the Pro Engine with the following key `semgrep scan` command-line arguments to maximize depth:
```
--pro
--interfile
--dataflow-traces
--max-target-bytes 1000000
```
Yet, the interprocedural and dataflow analysis appears to be less sophisticated than dedicated security linters for specific languages. It excels at simple syntactic matches (e.g., finding `System.out.println` in production code) but stumbles on vulnerabilities requiring taint tracking across multiple method boundaries or understanding library-specific sink patterns.

I am left questioning whether Semgrep's architectural choice for speed inherently limits its efficacy for complex vulnerability classes. Has the community observed similar gaps, particularly for vulnerabilities with significant operational impact? What strategies have proven effective for extending Semgrep's coverage—are we expected to maintain an extensive, highly-complex custom ruleset for every nuanced case, which itself becomes a performance and maintenance burden? I am seeking a detailed, technically-grounded discussion on the limitations of its taint engine and any proven methodologies for augmenting its detection capabilities without resorting to a second, slower SAST tool, as that would defeat our objective of maintaining sub-minute feedback in CI/CD.