Even if ninja is 100x faster, it really, really doesn't matter, at all.
In my (artificial) benchmark, make scaled poorly, taking 70 seconds to process 100k C files worth of dependencies, vs. ninja's 1.5 seconds: https://david.rothlis.net/ninja-benchmark/
Most of make's time was spent processing the ".d" files containing header dependencies (Ninja has a special optimisation for these files, where it reads them the first time they're created, inserts the dependency information into a binary database, then deletes them so it doesn't have to parse them in future invocations).
In real world projects, you often end up "abusing" make to add behaviour such as detecting if the compilation flags have changed, and this can make your makefiles slower; whereas ninja has those features built in. Apparently this made a big difference in build times for Chromium (where ninja was born). See this comment by the ninja's author: https://news.ycombinator.com/item?id=23182469
.SUFFIXES:
to nothingI have personally had Ninja turn multi-second long no-op rebuild times (e.g. run 'make' with no changes) into the 10s of milliseconds range. The no-op build is often the most extreme case but closest to the average case, which is "recompile after a small edit." The difference in interactivity is quite large in these scenarios.
If your project builds in under like 5 minutes from scratch on a modern laptop it probably is not large enough to see huge benefits (outside of pathological cases), but probably some benefit; but for larger projects the difference can be very pronounced, very quickly.