I would say that in almost all cases where someone thinks changing priorities ‘makes sense’ it really doesn’t.
Priority should reflect how important a job a given task has. This shouldn’t normally be changing in normal operation.
The one case I can think of where it might make sense is when the operating environment makes a major change of state. An example would be a collision-avoidance system. When the vehicle stops, this is no longer a 'high priority task, but you may still want to be running some of the system to keep up with the model of the world around you, but you aren’t as worried about needing to make split-second decisions. But unless you have some other task that needs to now become higher priority, you might meet the requirements by just dropping the activation rate, and not the priority of the system.
Now, if the same controller that was doing some of the collision avoidance now needs to handle say the operation of an aerial bucket, maybe that would be a case where you want to switch things. When the bucket is up, it has priority, and navigation systems run at lower priority, while when driving the bucket controls are lower and navigation was higher.
But even then, you could likely have just had the bucket system ALWAYS higher than the navigation, but that system is just blocked when driving, as it shouldn’t be in use anyway (of if you ARE driving with the bucket up, maybe it should stay high priority!!)
There are a few tactical situations where dynamic priorities are useful. Mutex Priority inheritance handles one of the major ones. Another one is you may want to create a task at a lower priority than yourself to let you completely create that task, and then raise it up above you if that is where it is supposed to be.
The normal reason I see for people wanting to adjust priorities is just that they did bad design, and the tasks burn time when they shouldn’t and that makes them think that they need to drop the priority of the task.