Something else that’s worth noting about priority inversion is that in app programming contexts it’s less likely to be a serious issue. It’s not unreasonable to know that a particular lock in an app is never held by truly low priority threads for example.
Whereas in a daemon programming context the default assumption is that everything is extremely low priority and then some things suddenly get boosted to high priority when the foreground app sends a message. It’s surprisingly easy to get stuck so badly that processes start getting killed due to being unresponsive for too long. I’ve even seen OSes fail to boot due to this back when we still used spinlocks in userspace.
I would still encourage everyone to care about priority inversion; it’ll especially pay off when the device is overloaded or overheated. But hopefully this perspective helps in understanding why we’re this careful about the topic.