As a general principle, there’s nothing wrong with a lot of “buttons.” A menu is basically a whole lot of buttons with different graphic design. So is a bank of links or tabs. They all do the same things –navigate or do some other command on the content. As long as your “buttons” are well labeled, organized, and distinguishable from each other, you can have 100s on the same page (if you include pulldown menus as just “temporarily hidden buttons”).
I think the issue you’re intuiting in your design is a problem in the “distinguishable” part. For the sake of speedy one-click action (a laudable goal), you’re giving your users multiple options with subtle shades of distinction, and that’s where it can get confusing. The solution is to break down your functionality into more discrete non-overlapping functions while still minimizing clicks. In some cases, it means prioritizing your functions, where rare scenarios may need a two or more clicks.
For example, when would a user want to click Previous vs. Save and Previous? If there were no changes, they are effectively the same (if saving takes a long time, then give the app the intelligence to only save if there were changes to the group). So the only time to click Previous versus Save and Previous is when the user wants to discard changes to the group.
That’s a bit problematic, because there is nothing about “Previous” that says “Discard Changes.” If fact, some users may assume changes are not discarded by merely navigating –they may expect that only closing the window without saving would discard changes.
It’s also a rarely needed function. Users usually don’t make mistakes. Furthermore, in this case, if they do, it’s relatively easy to remedy. If they click a check box and change their minds, they just click it back. Presumably there is a Delete button for every new category created, so that also has one-click undo. So the only time the users need Previous is when they really louse things up and can’t remember how to set it right. That’s really an edge case. So it’s okay if it takes more than a click to discard changes and move to the next or previous group.
You could have this, where save is implicit:
Exit, Previous and Next all save. If usability testing suggest users hesitate because they think Exit doesn't save, then consider labeling Exit as "OK" or maybe "Submit," which imply saving and leaving the app/page. Only label it "Save and Previous/Next" if testing shows users are afraid of losing work. My policy is add clutter only when testing shows it's necessary.
The Reset button reverts the group to what it was when the users arrived at the group in case they irreparably mess things up. However, given how rarely they’ll actually need this button, consider omitting it. It’s a land mine that can throw away the user’s work with one false click. Or better, make it an Undo button that reverts changes to the group one click at a time. Yes, it could be many clicks to fix a big screw up, but that’s exceedingly rare.
Next consider your Previous and Next buttons themselves. What advantage do they have over the users clicking the group label themselves (represented as links or tabs), as maxathousand suggests in a comment? That gives the user one-click access to any group, not just the previous and next one. The only advantage to also including Previous and Next is if users often page quickly through all groups in sequence to check them. Then Next (and maybe Previous) allows them to do so without moving the mouse. If that isn’t a common task, delete those buttons: