eh, that's not really the case in a lot of developer jobs these days. A lot of agile/scrum adoption/bastardization has meant that all work done has to be decided by the team and pretty much every piece of work has to be approved by a product manager. This can often lead to some demoralising meetings where you can either lie about the effort/risk/goal or you can give a true value estimate that gets shot down. If you lie, you can end up spending your own free time working on that refactor or documentation etc. For most devs working on a codebase, its not theirs, and they don't determine what has priority.

In reality, for a lot of people, if you start refactoring the codebase while waiting for a new task you are likely to break something and its just not worth the hassle for the developer or the company.

Learning new tools is always great ofc but it can be very hard to find the motivation in such a role, where unless you are a senior developer, you probably won't have much say on adoption, and you will likley just develop a half baked understanding of a new library that you will never get to use in production. Its much better to have some real free time where you can focus on your own projects and learn that way.

So in short, maybe it should never be the case that devs are in that position, but it often is. Especially for devs with less experience