As another commenter mentioned, MiniZinc is a DSL for modelling combinatorial optimization problems, and Google or-tools is a solver that can solve such problems. So it is not really comparable in that sense.
The benefit of using MiniZinc instead of a specific solver directly, is that the user can try different solvers easily to find the one that works best for their problem. The drawback is naturally that it may be harder to use solver specific features.
The MiniZinc challenge is a competition that pits these solvers against each other. Note that the group that runs the challenge also develops solvers (which are ineligible to win prizes in the challenge, but are participating), and that these solvers are sometimes better than Google or-tools (no solver dominates all other solvers). See https://www.minizinc.org/challenge2020/results2020.html to get the full results.
Finally, while solving speed is of course important, it is not always the most important issue when developing a cobinatorial optimization solution. Choice of general tech stack, documentation, support, ease of integration, local expertise, and so on are important issues, as it is for every large dependency choice.
Personally, I tend to use MiniZinc for prototyping and experimenting and for solving simple problems.
For building larger solutions, I would also probably use a solver directly. Reasons for that would be customization, integration, and data handling issues. For me the go-to system would be Gecode, but there are a lot of very interesting and varied solvers available.
Worth noting is that MiniZinc is starting to get more and more support for integration into large systems, for example with the python interface (https://pypi.org/project/minizinc/).
Basically this for me too; MiniZinc is great whilst you don't really have the full problem nailed, when it's harder to pick what you'd like to focus on using sovler wise.
I use Python to generate DPLL and likewise with MiniZinc. It’s no different from SQL: there’s something of an impedance mismatch that’s already felt in eg Sympy.
The benefit of using MiniZinc instead of a specific solver directly, is that the user can try different solvers easily to find the one that works best for their problem. The drawback is naturally that it may be harder to use solver specific features.
The MiniZinc challenge is a competition that pits these solvers against each other. Note that the group that runs the challenge also develops solvers (which are ineligible to win prizes in the challenge, but are participating), and that these solvers are sometimes better than Google or-tools (no solver dominates all other solvers). See https://www.minizinc.org/challenge2020/results2020.html to get the full results.
Finally, while solving speed is of course important, it is not always the most important issue when developing a cobinatorial optimization solution. Choice of general tech stack, documentation, support, ease of integration, local expertise, and so on are important issues, as it is for every large dependency choice.