Thanks for opening the thread. Your analysis are pretty much right, however the rfc-2136 plugin does work for multi horizon setup (as your example above points out).
The Certbot plugin indeed interacts with the Bind using DNS UPDATE as its name suggests.
When communicating with the DNS server, it tries to update the zone that’s configured in the DNS server software. In case of multi horizon setup, this view may be internal or external, or anything in between (as there’s no hard limits how many different facets the DNS server might have).
If we assume that the server has been configured to serve different results for internal view, and different ones for exrternal view, the Certbot plugin (or nsupdate in that matter) tries to modify the zone in the view of the source address. In the typical case this might be the internal view. The issue arises if the internal view is modified (or doesn’t have the TSIG key configuration in place) and Let’s Encrypt tries to retrieve the validation token from another view (in our case, it would probably be the external) which of course doesn’t have this modification.
The configuration snippet posted above as an example adheres to multi horizon setup scheme, but in fact provides just the default single horizon functionality, as the served zone is exactly the same for both views.
All in all, this is not a bug in Certbot plugin, but merely a technical limitation of multi horizon setup in BIND.