By that argument, Mirage is against the Unix philosophy too because it bundles the kernel with the application. I don’t think the Unix designers ever wanted blind adherence to the ‘philosophy’; there are different contexts with pros and cons for all tech decisions.
I don’t feel like these are antagonist goals actually. We can (and IMO should) preserve the different tools, which should have their autonomy, with the many advantages of the Unix philosophy: if you know what you’re doing you can swap out one of them, responsibilities are clearly delimited, etc.
On the other hand, it doesn’t prevent us from having one of these tool act as a frontend/driver for the others, so that new users or users that don’t care about these details can have a seamless experience.
Personally I will probably still want to deploy my own Opam repositories and hack around with the tools, but when quickly testing another project or when onboarding a member of my team I certainly don’t mind only needing to type dune.
I think it’s worth emphasising that Dune’s package management isn’t driving the opam tool, rather it’s consuming the same data as the opam tool (in a similar, but rather larger, way to how Dune consumes META files, but doesn’t drive ocamlfind).
The difference should not be noticeable to the user, other than that it’s faster - I believe it’s still the case that switching between Dune’s package management and going back to an opam switch is as simple to the user as switching between having a copy of the a package repo in your local workspace (in vendor/ or whatever) and then deleting it to go back to using the opam package from your switch.