The comment from @mickmackusa is essentially correct, but there's some context missing, perhaps, from your question that makes me wonder if you're not asking a wider question. There are wide variety of reasons for the overrides you're seeing.
In an MVC world "save" is both a controller and a model method. It stems from the concept "separation of concerns." The model's concern is not interacting with the rest of the system; its concern is ensuring the data is valid and then persisting it.
When you interact with the system the controller will get the "save" request from you first, and it may have some housekeeping of its own to do before passing the request on to the model. If it does, then the controller's save method needs to be overridden to achieve that.
Another possible reason is because the form itself that has been submitted may contain data from (or data destined for) two different models. That's not "clean" from a pure coding standpoint, but we live and work in the real world, with real users, who don't want to deal with three different forms simply because that's a more efficient way to store the data -- a user's experience should never be as a slave to the database. In those cases the controller "save" task will ensure the data gets routed to the right model. This approach can happen if you build your system around the user's tasks, rather than the database tables. (I'm not commenting upon which is the better approach, because frankly it's not a clear-cut decision; there are cases when either is better than the other.)
Another cause for overriding the method is because the class itself doesn't follow the single-responsibility principle very well (directly related to the comment of "from many walks of life"). There are several methods that really should be broken up into 5-6 smaller methods; the large method gets overridden often because there is just one single line, sometimes only vaguely related to the task, that needs to be changed.
There's a school of thought called "skinny controller - fat model" that says everything to do with the data belongs in the Model, the controller is a glorified switchboard, simply making sure the model gets the data it needs. There are other schools that insist there need to be other classes around the model and controller that take care of the business logic; the controller controls and the model saves, and other classes do the other things. There's really never been an architect that said "this must go here" so we have what we have; a thousand different flowers blooming in the code. MVC has never been so rigidly defined that code can only be written in one manner to satisfy it (one of the early MVC approaches gave every single individual area on the screen its own controller, for example; I remember someone revived that idea a while back under the name "Hierarchical Model-View-Controller").
All that is by way of supplying context for this: There really isn't enough information in your question for you to get a concrete answer. When you see something in the code and you don't understand the why of it, ask a specific question about that piece. Maybe there's a good reason why the general rule doesn't apply in that case. Maybe the right answer is "Ooops. You're right. That doesn't belong there."
In which case, you may have just found your first opportunity to contribute to the project.
save()snippet to offer in your question so that an answer can be provided?