Hardly fool proof since there are many legal names that are not legal IDs.
Also names can repeat, either within the same form (radio boxes for example, but other elements too), or in different forms. IDs cannot, and must be unique.
Nope, this does not work in general and is even worse for checkboxes and radios: it is very common to have groups of checkboxes and (especially) radios which all have the same name, differing only by their value. In that case, all checkboxes/radios will have the exact same id, which is quite obviously not correct.
And you can get that with any form field type.
Now you say "well you're using a cool form library, so it can just make ids unique per form and you get "checkbox1", "checkbox2", ..."
Except ids are unique per page, you could very well have a thousand forms with the exact same names in them, and you'll still need all of those inputs to have different ids.
We're comparing this to writing bare HTML by hand.
All of your criticisms apply equally to the technique it replaces.
Now since however, I didn't really specify what went into the checkbox function behind the scenes... lets assume.
1. It creates unique id variations.
2. It handles the case where you have multiple checkboxes with the same name. Perhaps by passing in differing parameters (e.g. checkbox(id='?', name='foo')).
You're criticizing an unspecified strawman example. Until someone actually goes out and writes this library, neither you nor I know how 'fool proof' it really is and what edge cases it leaves unspecified.
But the "fast" thing to do is to add the long form declaration of the label into your templating function library.
In the future it would be much quicker to write something like: print checkbox('foo')
And get the 'fool proof': <INPUT type="checkbox" name="foo" id="foo"><LABEL for="foo">Include bar?</LABEL>
as output.