It was closed because the original author of this RFE (that's me) didn't need it anymore and therefore didn't have any inclination to implement it. There were (far) more important issues to concentrate on, and this wasn't one of them.
The blocking issue with any bugfix and/or enhancement with FOSS is (usually) to have a software coder who is both capable of implementing it and also keen to have it; I decided that it wasn't going to be me (so I closed it), but if you (or someone you can persuade) fits those criteria then please do get involved 
FYI, when I originally raised this issue, Jenkins pipelines weren't the big feature that they are now; if I were to need to update a docker template today, I think I'd write code to do that in groovy within a Jenkins pipeline.
The big problem to solve in order to make this RFE viable is to work out a good way of identifying which template(s) need to be updated - there's no requirement for a docker agent's template "name" field to be unique across all templates, so that gives us the problem that there is no (good/easy) way of unambiguously identifying the template(s) to update. When I originally raised this RFE, there wasn't even a name field in templates (the nearest equivalent was the "docker image", but it's perfectly reasonable to have more than one different template using the same image, so that's not unique either...)
The next problem would be how to create a means of updating any/every part of the template without causing massive code/data duplication - we don't want to make the plugin code more difficult to maintain...
Overall, this could turn into a non-trivial bit of work - it'd need all sorts of functionality for "how to identify what templates to affect" as well as lots of (boring but easy to get wrong) code to allow users to add/remove/replace field values, and that's even before we get onto permissions issues of limiting who could trigger this.
...that said, if you believe that need this, feel free to re-open it (or raise a new issue on github) and detail the exact functionality/requirements/use-case(s) you're after ... and then, once the overall approach/design is agreed, be prepared to implement and submit a pull-request for it so the code can be reviewed 
I plan to revisit this feature, as such administrative task should not be implemented as a builder arbitrary user configure on jenkins.
A simple option could be for the template to use a variable for image name, this variable being updated when image is rebuilt. Another more docker-centric approach would be to define image by it's sha256, not just tag, and get some hook to tell jenkins this image has a new build with updated sha256, so jenkins will use it for new build. When image is built within Jenkins we could then automatically trigger this update.