I certainly think whatever incarnation of make that you would summon to do some sort of multi-machine configuration management (per your chef/ansible comparison) is something I would do everything in my power to avoid.
: fred@dejah ~ $; cat >hello.c
#include <stdio.h>
int main() {printf("hello\n"); return 0;}
^D
: fred@dejah ~ $; make hello
gcc hello.c -o hello
: fred@dejah ~ $;
You're free to love make all you want, but I've been there, was effectively held hostage by it for lack of better options, and hate it. Automake and asociated tools was the first attempt at getting us out of that hell, and it didn't succeed but cmake/premake/bazel are doing a whole lot better.
Many a time I see unslim and unclean Makefiles where the problem is mostly that someone started to use make then tried hard to use make as a single unifying tool for too many things, some clearly not belonging to make.
There is nothing wrong with writing wrapper and helper scripts or programs alongside a Makefile, so that make is only bothered with its dependency graph building.
History has shown that having sensible defaults for common use cases and workflows goes a long way to reducing complexity and ammunition for self-afflicted foot shooting should be isolated and explicit.
So if you invoke a tool that expects some arguments wrapped in parentheses, you need to do stuff like
LEFTPAREN:=(
RIGHTPAREN:=)
$(addprefix $(LEFTPAREN), $(addsuffix $(RIGHTPAREN), $(PARAMS)))
...like $(patsubst)?
$(patsubst %,(%),$(PARAMS))