As Ivan Jaros said, all config entities can have dependencies on modules and other config entities, both automatically derived based on code (e.g, a field depends on its field storage and entity bundle it is added) and manually set (in an enforced sub-array with the same structure)
Dependencies ensure that the required dependencies are installed and they are installed in the right order. Which is important if you import a new node type with fields, display configurations, views that list them and so on.
User roles currently don't have automatically derived dependencies, but they actually should have. They should depend on the modules that provide the used permissions, which is a bit tricky since permissions don't give you that information especially not for dynamic ones that depend on node types, filter formats and so on. That's why the key is always empty for them.
We should open a core issue to try and track this better, that would allow roles to clean up permissions when e.g. a node type is deleted or a module is installed. But it's not a major problem since nothing happens if those permissions don't exist anymore.. it's just a string and if nothing asks for it, then nothing happens with it. The only problematic thing is that you a) end up with cruft in those config objects and b) the permissions could get active again when you e.g. delete a node type and add again with the same name. You might not expect your permissions configurations to survive that.