Providing configuration and customisation through the settings page makes it easier for CMS systems and the like to integrate widgets on demand for a user (who can just paste an ID, rather than needing to meddle with HTML), without every implementation having to create a unique set-up interface for fonts/colours and so forth, that would then be obsolete and semi-functional when we add more. Having an ID for the widget means all of that configuration can be kept at the source of truth.
Not all of that is realized yet, and some of the client-side set-up needs to exposed on the server-side to be complete, but hopefully it will make widgets much more accessible to any level of user in the long term.
Both of your points (registration and response to cases abuse) are also benefits. As you can observe on the forum over the past week, the big API change and its effect on the old timeline widget caught a lot of people by surprise, despite 8 months of announcement and preparation. We didn’t have any way to contact people who had implemented the old timeline widgets to alert them to the need for action. It’s very frustrating for them, for us, for everyone. And while such a massive change is not likely to occur again, it’s better to assume that we’ll need to alert people to something some day, and having it linked to user accounts means we can.
Ben