I remember my first job out of college, I was asked to write code that caused our software to cheat at a certain industry benchmark. I was very junior, but still realized it was wrong. I finally worked up the courage to tell my boss that I had an ethical problem with doing this and wouldn't do it, and to my surprise, he said "Oh, that's fine! We treat software developers well here. I'll just give you a different bug ticket to work on!"
Jim, a few cubicles down from me had no problem writing the benchmark-cheating code. It's kind of futile.
It is worthwhile for us to read and reflect on the ACM Code of Ethics and Professional Conduct.*
"Should not apply" is a very strong phrase. Would you be willing to humble yourself in a junior position so that you could learn? Are you willing to put in the time and effort to learn the ins and outs of the platform? If so, I think you'd be a great fit as a junior systems engineer at a 50-500 person org that has the self-awareness to put you on a team with more experienced engineers who can show you the ropes. If anything, you're a great candidate because you'll already have some programming experience under your belt which minimizes the barrier for learning syntax and language-agnostic programming concepts, allowing you focus more on actually learning how everything works under the hood.
I work professionally on computer vision software, and quite frankly one of the biggest barriers we have now is that the people who are deploying our ML code have the experience with all the experimental tooling (PyTorch/Python) but not as much with what's going on under the hood, and thus we're leaving lots of performance on the table.
My personal definition of "systems knowledge" is "can you answer 'how does this work under the hood?'" to the point where we're talking about assembly/bytecode and drivers. It's more tedious than learning the Java standard library, but I wouldn't necessarily say it requires more intellectual power. It just takes time.