As a manager, I am responsible for conducting performance reviews in which quality and technical contributions are taken into account. I know, this is really three "pros", but they are all directly related. A hands-on manager may have more intimate knowledge of what is being coded, which also gives excellent insight into the accumulation of technical debt and the quality of work done by others on the team. There's no better way to know what is included in a release than to see it firsthand. It may have put my team at a disadvantage to have me leading the charge while constantly getting distracted by other, more pressing tasks. As a manager, my days were often filled with disruptions, i.e., tasks that came about without warning and needed immediate attention. This also applies to "getting back into the groove" when disruptions occur.
I still reviewed code and was very involved in the day to day technical decisions - that is, I am a technical manager. I went from being the team technical lead to "hands-off" management overnight and stayed that way through my entire tenure as manager. So, for over 5 years I haven't touched code. I always felt that this approach was in the best interest of the team and would ultimately allow people to focus on what they do best. However, I also had managers who were very technical but stayed away from the any coding. Granted, most of my experience with management was with nontechnical folks who relied completely on the expertise of the team technical leads for insight into the code. It was always a given that the manager didn't touch the code.
Prior to that, I had more 11 years of experience in software development and had never been on a team with a "hands-on" manager. This isn't something I have thought about much over the last 5 plus years, when I became the Application Development Manager for my team of Java developers.