The setting API, which its usage is being demonstrated in that code is meant to be use as a framework to create settings pages which result in update of values in options.
Widget settings are is a somewhat more abstract level. They are stored in options, but there is no flexibility how they are stored, they are all stored as array of mostly constant fields of settings where the index is a widget identifier.
This abstraction aka widgets API follows a different flow than the settings API.
There is no problem in calling get_option anywhere that you need it the widget code, but this is the only integration that you should probably have.
You should not set an option when a widget is saved because this kind of side effect will confuse the user, and the customizer will (don’t remember why) complain.
You can manage widgets is a setting page, but how widgets are stored and retrieved is one of the least documented areas in core, and while it is surely possible, it is not very trivial and I don’t remember seeing anyone doing that.