The idea is to have an 80/20 build system:

For the 80% of use cases, you have homogeneous build commands that are the same across projects (such as a makefile with build, clean, test, etc). This calls the real (complex) build system underneath to actually perform the action. You shouldn't need to type more than 15 keys to make it do common things (and you CERTAINLY shouldn't need to use ANY command line switches).

Then for the other 20% of (complex) use cases, you call the underlying build system directly, and have a document describing how the build system works and how to set up the dev environment (preferably with "make dev-env"). Maybe for self-bootstrapping systems like rust or go this isn't such a big deal, but for C/C++ or Python or node or Java or Mono it quickly becomes too bespoke and fiddly.

Then you include tests for those makefile level commands to make sure they actually work.

There's nothing worse than having to figure out (or remember) the magical incantation necessary to build/run some project among the 500 repos in 15 languages at a company, waiting for the repo owner to get back to you on why "./gradlew compileAndRun" and "/.gradlew buildAndRun" and "./gradlew devbuild" don't work - only to have them say "Oh, you just use ./gradlew -Pjava.version=11 -Dconfig.file=config/dev-use-this-one-instead.conf -Dskipdeploy buildAndDeploy - oh and make sure ImageMagick and Pandoc are installed. They're only used by the reports generator, but buildAndDeploy will error out without them". Wastes a ton of time.

Yes. In the example of gradle I setup all specifics to the well know lifecycle tasks: check, assemble and in some cases publish. Some projects are more complicated specifically when you can really use the rule of: 1 project one assembly. See android with apk vs bundle. Here you may need more specific tasks. But I try to bind CI (be it Jenkins or GitHub actions) to only know the basic interface. But I meant specifically the believe that build systems and tooling around is too complicated and unnecessary.

Having Make shell out to the real build system is a nice compromise. Then you can stick your tests and stuff in there too