We do a similar thing on my current team with respect to having a day to work on things that we think are important but aren't necessarily on the backlog. It seems to work reasonably well for this team, but there are some downsides.
Explaining this well is really difficult, so I hope you don't mind me resorting to a metaphor. Imagine you are the chef of a restaurant and you work alone with your one waiter. You run the kitchen and they deal with the customers.
Quite a lot of your work will be directly related to customer orders. You need to set the menu and go shopping and prep all the food. In addition to that, there are also some things that you need to do all the time like sharpen your knife, disinfect your cutting board, etc, etc. You could prep more food if you didn't have to do those things, but if you don't do them, then things will be quite a bit slower, so you have to budget some time for that. Still, these are things that you can do when customers aren't in the restaurant, so it's easy to budget.
Once the customers come, you have to react to their orders. However, that's not all you have to do. You also have to clean your pans, wipe your board, keep your knife clean, shuffle food between your fridge, your board, your pans, etc. You also have to do extra prep work for things that you estimated wrong at the beginning of the day, or for special orders that come in.
You could just pile up dirty pans as you go, but eventually you will have nothing to cook with. You have to find time to clean them as you go. You could take everything out of the fridge and leave it on your board, but then you won't have room to prepare the food and your food will spoil.
Prioritising this work is not something that can be done in a meeting. The chef doesn't stop and chat with the waiter about whose food has the highest priority and negotiate, "Maybe wash that pan later, so that we can serve this dish first. We'll take the hit of unsatisfied customers who have to wait and watch you wash dishes for half an hour later." The judgement call is left up to the chef because it is the chef who knows better than anyone how to keep a constant throughput in order to keep the customers happy.
It doesn't mean that the waiter has no say in the matter. If they perceive that something needs fixing now, they must say it, but the chef needs to figure out how to accomplish that while keeping the kitchen moving.
In our software shops, we tend to listen to our stakeholders and given them literally what they are asking for. We often don't make the judgement call correctly of how to keep the "kitchen" moving. Our project managers often press the big red panic button and say, "Stop everything and just fry the steak. Don't wash dishes. Don't put the meat back in the firdge. Don't clean the board. Don't clean your knife. Don't prep for the next customer." -- with predictable results.
Adding a 20% (or whatever) "budget" for allowing the developer to choose what to do is great, but the reality is that the developer needs to be able to choose what to do next 100% of the time -- and they need to have the ability and experience to choose correctly most of that 100%. This is the tricky part. If you do not have people like that on your staff, then you may be stuck trying to get by with planned work. It's going to be a crappy kitchen: food left out to waste, knives unsharped, dishes piling up in the sink. You might be fortunate enough to have someone on your team who will choose to wash they mountains of dishes in their "20% time", but the odds are fairly slim. What you really need is a chef who can direct traffic in the kitchen and who has the authority to make judgement calls 100% of the time.
Note: If you ever get a chance to watch on open kitchen with a single chef who does everything, it is a fascinating experience. Only a small fraction of their time is spent actually cooking your food. Most of it is shuffling things around, cleaning and organizing. Yes, most professional kitchens have specialized positions, but I think this is metaphor is closer to the reality of programmers.