It's not that unrealistic, as long as you have a wide enough definition of "good."

I don't think you want to hire someone for an SRE role who doesn't understand algorthims well enough to do detailed analysis of the codebase, including, say, rudimentary big-O analysis of the code. Good SREs read quite a lot of code and if they're debugging a performance issue and the code contains portions that are obviously exponential or factorial in time, you want them to be able to see and recognize that quickly as a potential cause of the problem being debugged. The same is true of problems caused by bugs or anything else. Likewise, good understanding of what's possible and not possible with software is necessary for area to file (or potentially close) reasonable PRs for the codebase.

The person who thinks in terms of page faults and systems analysis may take a little more time to find the optimal algorithm for an abstract problem than someone who only thinks of abstract problems. But they should know enough about software and computers to recognize the limits of their knowledge, and that's the hard part.