The WordPress Settings API is a great way to quickly add custom settings pages to your plugin. By leveraging the options functions and abstracting the way that the settings are retrieved and displayed it takes a lot of the heavy lifting out of adding your own options pages, and provides great flexibility in the way your settings for your plugin options pages are displayed.
However there are some aspects of the API which I feel do not work very well.
When it comes to linking the sections with the fields and then registering your new section it all feels a bit clunky. I also think that the way you have to write your output code for a field or section in a function which returns the HTML does not lend itself to clean design.
It is considered better design when the code for presenting data is separated from other logic within an application (see Martin Fowler’s discussion on GUI architectures for an interesting discussion on GUI design). This is for a number of reasons.
When everything is mixed in together it becomes more difficult to find and fix errors within the application. Often the login used to present data can be reused in other parts of the application. By mixing the presentation logic and control logic or business rules together reusing the presentation logic becomes much more difficult.
So my solution, to what I see as two downsides in the Settings API was to write something which still used the Settings API underneath, but made it simpler to use, and separated out the presentation logic.