Yep, there's definitely a way to write code intentionally, for the reasons you listed, and I approve of that! But you'll see a lot of engineering managers coding because they are trying to help the team reach its next deliverable. This is usually short-sighted.
I think of it as the management control loop: "I have some spare cycles -> what is the most important work I can do for the team right now?" Coding can be the answer. But some people's control loop seems to be more like: "I have some spare cycles -> what is the most interesting/rewarding task I can do next?" The latter might lead to a lot more coding, but it's not good for the team.
No idea where these guys work where they can just roll up their sleeves and start coding. I would love to help out but there is zero time for me to code.
One of the reasons I keep doing it is because I know if I fall off the wagon it will very quickly translate into that situation. As long as I have everything set up like the actual devs do and know all the processes, it isn't a lot of time for me to jump in and do bits and pieces. And even though its a very slippery slope, there are absolutely cases where it takes longer to explain what I want than just to do it. Sometimes I will start it off to get the architecture right and then leave a trail of points to complete it with someone on the team. So there are times when it's a "time saver" and it's a win all round.
I think of it as the management control loop: "I have some spare cycles -> what is the most important work I can do for the team right now?" Coding can be the answer. But some people's control loop seems to be more like: "I have some spare cycles -> what is the most interesting/rewarding task I can do next?" The latter might lead to a lot more coding, but it's not good for the team.