SREs and coding is a contentious topic. In most situations, SREs end up spending a lot of time on operational tasks, even while being efficiency and automation focused. This means that SREs don't spend as much time coding as a full time developer, which puts them in a very disadvantageous position as far as programming rigor is concerned.
Also, SREs are typically responsible for multiple services or applications, unlike developers who may be more focused on a small number of applications. Gaining deep knowledge of large codebases can be a daunting task especially if the focus is diffused by interrupt-driven nature of SRE work.
To be very good in coding and be able match a developer's level of expertise in programming, SREs need to spend more time coding on a continuous basis, which may not be possible.
Also, the question arises - if an engineer is a great developer, why would he or she opt for an SRE role? The pure development roles seem to have a better career path.
Also, the argument that SREs should spend most of their time coding and not in operations seems a little disconnected from reality. Not all operations is evil and not all code is an angel either. As someone said, "the best code is the one that was never written". Running operations efficiently and reliably is an important goal for SREs and coding can be helpful in achieving that goal, though it is not the only means to get there.
So, what is a reasonable expectation for an SRE when it comes to coding? Is it practical to have two cadres of SREs -- development focused ones or "SWE SREs" and operations focused ones or "Operation SREs"? Could they be a part of the same team? Is it practical to rotate people between these two roles?
I hope this question is not dismissed as opinion-based.