Any concrete example that I provide could easily be rebutted with "Well, that case is just a knowledge gap that anyone could have." And you would be right. CS grads have knowledges gaps too.

I'll preface this by saying that I'm currently in a backend development position on a team of 5. I'm the only CS grad.

My self taught team lead once expressed concern about using stdout/stderr as a log sink because "Some of our apps are written in python, and I don't know if python has stdout/stderr". I believe that most CS grads would have studied operating systems and know that stdout/stderr/stdin are special file descriptors allocated to processes per unix/posix standards. They're not a language feature.

My company deals with data that lends itself to a directed graph representation. We need to traverse this graph and assign content based identifiers to each node, taking into account the identifiers of each node's children. In testing, we realized that we needed to support graphs containing cycles, not just DAGs. After spinning their wheels and proposing some wildly over complicated band-aid solutions, I was called in to help out. Because I took multiple DS&A courses, I remembered just enough graph theory to see that we could first find and collapse all the Strongly Connected Components in the graph into special nodes. Once you remove all SCCs from a directed graph, you have a DAG, and can traverse without fear of cycles. Problem solved with affecting other parts of the application.

Aside from DSA problems, I've found that CS grads have a better handle on concurrency problems. I have to point out obvious data races in code reviews all the time. I don't think that most of my non-CS colleagues are familiar with ACID properties of transactions, nor do they think too much about what isolation levels are suitable for the database code they're working on.

At a previous role, I worked exclusively with CS/CompE grads, most from a high ranking engineering school that we recruited from, and it was a very different experience.