Yes, agree on the API.
The add-in would be fun to script but only for short term fun. We are doing our best to make any such add-in obsolete very soon.
Because Style is already highly visible/accessible in tables there are all sorts of UI things in the "convenient" direction that can be done with surprisingly little effort. Some biggies that come to mind:
1. Log a history in some system table and then provide some UI controls to exploit that history. You could save a hundred prior StylePixel strings, for example, with total ease and not significantly increase the size of a project at all. It's not like having to save a hundred prior versions of the whole data of a drawing or image. Once you have such a history you can go back and forth between prior versions, a very fluid, Photoshop-style Undo/Redo, at least for Style.
1a. Over time, that is something we can introduce for other characteristics that are stored as simple properties, such as coordinate systems. Have a history of all prior coordinate system JSON strings? No problem going back to a prior version. The plan is to provide more Undo and multi-step Undo where that does not either kill performance or unacceptably increase project size.
2. History is cool but it is also desirable to be able to save/load styles, share styles more fluidly between components (copy/paste, etc...), have favorites, etc. The more extensive Style options become the more this will be desired. This can take more work than 1) above because while there is no rocket science involved there are a bunch of controls that must be provided with a good, fluid arrangement and sense of taste.
The focus, of course, continues on bringing in big things like the recent migration of raster styling from the old Edit-Style dialog to the Style panel, but we want also to find time in cutting edge builds for a few simple UI improvements like the above as builds come out. This will get done in the weeks ahead.