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.
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.