thanks

I think in this particular case, it did not hurt, because if you look at the current code (e.g. for cppcheck):

let &l:makeprg = 'cppcheck --quiet'
[...]
exe 'CompilerSet makeprg='..escape(&l:makeprg, ' \|"')

E.g. the :CompilerSet command, which executes :set in the :compiler! case, would first retrieve the local value of the makeprg option value and use that value to set the global and local option value again. So it is not like the current solution is broken. But I think just using :CompilerSet is slightly easier to read and understand

Not broken, but breaking user expectations as set for a :help global-local value such as &makeprg (different from a :help local-noglobal value like &filetype) should not touch the local value at all from what @romainl explained; I falsely assumed :compiler! to change both the local and global value (say, similar to what I was used to from set spell which behaves like setglobal spell and setlocal spell at once).

Not broken, but breaking user expectations as set for a :help global-local value such as &makeprg (different from a :help local-noglobal value like &filetype) should not touch the local value at all from what @romainl explained; I falsely assumed :compiler! to change both the local and global value (say, similar to what I was used to from set spell which behaves like setglobal spell and setlocal spell at once).

I don't think this is true, :set does have some pecularities for handling global-local` options, in this case, it empties the local option value.

let &l:makeprg='local make'
let &g:makeprg='global make'
set makeprg=set
echo $'local: -{&l:makeprg}- global: -{&g:makeprg}-'

echoes: local: -- global: -set-