Concerning your statement:

"It probably only makes sense to allow the last build in a sequence of failed builds to become the new reference, because otherwise you would have to recalculate the quality gates for all following builds up to the last build."

I don't know how difficult it is (CPU intense for Jenkins?) to recalculate the quality gates for all following builds up to the last build, but from a user point of view:

As soon as the pipeline measures more issues because a new tool is detected used by the git repository then it is quite possible that the defined quality gate will always fail. This is a gap in the plugin. It is not possible to define tool-specific quality gates (new feature!) but apart from that, imagine a project which needs a little bit more flexibility and then a PO comes along and says that is also good enough that is our baseline for now. But on a develop branch the developer push quickly. So choosing the last one would be maybe not right one. Why not choosing the first unstable / failed one after the latest successful build?

Also I'd like to know if the "reset quality gate" button could be restricted to certain user/group configurable via Jenkins access control?

Maybe it would also makes sense to create a new page that provides a more comfortable way to alter the quality gate references (Quality Gate View). Then we can remove the buttons from the current list providing a more clean user interface.