This feature must be implemented for RC 2 in order to fully resolve this rather serious bug involving runaway table growth:
https://www.vaultwiki.org/issues/3911/
Note that the issue with Wanted Pages being filled during imports unnecessarily was fixed in RC 1 since Wanted Page detection is deferred until all existing pages have finished importing.
Additionally, Wanted Pages having an incorrect link count and not cleaning up when the "wanting-page" is updated should also be fixed per the aforementioned bug report. Thus, most reasons for wanting to "Clear" the data should now be mitigated.
However, it may still be necessary to rebuild this data in the future if there are still bugs in the tracker or other issues.
Deleting Wanted pages for a particular prefix is not really the best implementation, since they cannot be added on a pre-prefix basis. Links, regardless of prefix, can appear anywhere, so rebuilding them would have to be a global effort.
Since the need for a UI-facing builder rests on the assumption that there will be bugs in the system, much like a UI-facing tool to cleanup corrupt delete or book data would be, this tool does not need to be UI-facing, as it will mostly be a waste of visual real estate. As long as it can be accessed easily enough programmatically, that should be okay.