Sorry for the delay.
First of all I want to let you know that the Sucuri plugin does not touches the database during the execution of the reset action, it only deletes the folder where the selected plugins are stored. If the Sucuri plugin has access to write in the plugin’s directory it will proceed with the download and installation of a fresh copy of the deleted plugins, this operation is handled by WordPress itself by executing the same code that runs when you install a plugin via the WordPress Plugin Manager. This is the main reason of why the operation fails silently, because WordPress does not returns any error information to the Sucuri plugin during the execution of its code.
Depending on how the other plugins are designed, the customizations may be recovered from the database.
When you see “The plugin [PLUGIN] has been deactivated due to an error: Plugin file does not exist.” it means that the Sucuri plugin was able to delete the directory where the other plugin was installed but was not able to install the fresh copy for some unknown reason (remember that WordPress does not reports the error messages so the Sucuri plugin can’t report anything to explain the failure). Since the plugin does not exists anymore WordPress automatically deactivates it.
Reinstalling a software using a 3rd-party tool is always a risky move. There are hundreds of plugins in the market, all of them with different design patterns, with different structure, with different quirks. We can’t cover them all to verify that the operation will always succeed.
I will include a warning message in the “Reset Plugins” page to warn people about the risks of this operation and advice them to create a backup of the entire plugins directory before using the reset tool. This will be available in the next version of the plugin.