The one change I would suggest is putting the package manager names as constants all in one place. That way, you can't make a typo in one of the checks in the if statements. That, and maybe replacing the if-else chain with a switch statement. Might help remove some duplication
It is simple, it works, everyone can understand the code and update it.
That is actually very valuable, especially for a project like this which tends to need maintenance to keep alive (whenever some wrapped command changes).
It means all logic for a specific package manager is gathered in one place instead of spread out over many files and the compiler can prevent us making stupid mistakes like forgetting to add a subcommand or mistyping the packagename in the big if/if/if statement.
In the current implementation we have (X = numberOfPMs*numberOfCommands) string compares which are not checked by the compiler. That means X potential typo's that each need a unit test just to verify that the implementation is hooked up correctly.
I would say that a class based implementation like this is simpler and prevents more errors during maintenance than the current version.
Don't put down OOP and classes just because hating on GoF patterns is all the rage in 2018, they exist for a reason. This is a clear case for applying them.
Translating commands from a generic command interface to specific commands is a great case for polymorphism.