you're actually asking 2 questions in one.
The first, what are the benefits of REST (explained in a way non-
programmers can understand).
Take a look at "How I explained REST to my Wife":
The second part of your question is more about "how is splitting
things up better than keeping things in one simple file?"
Unfortunately that's much more difficult to explain in a way that's
meaningful to non-programmers. That part of your question is more
about "sound development practices" which can't be considered 'rules'
because there's so many damn exceptions. So when you read this, bear
in mind that there's a tug-of-war going on between all the objectives
you have. Nothing is absolute.
But basically the issue is "one simple file".
You *could* write your rails app as having only one controller. No
views, no helpers, everything done in the controller. Heck you could
even write it as one *action* in one controller. That's one file,
but I assure you, it would *not* be simple.
So you start to break it down into logical chunks. You split things
up according to MVC, asking questions like "does it makes sense for
models to care about http requests?". All along the way you are
adding files (and classes).
As you do that, it might occur to you that *adding* classes
(splitting your app into controllers or models or views) has actually
reduced your complexity. Eventually you may come to the conclusion
that a lot of objects which do one thing really well, working
together to complete a task, is a *heck* of a lot easier to manage
than a few objects which are like swiss army knives.
Which leads us to how Rails does REST by default. By using those 7
controller methods as a threshold, it's a great reminder to take a
step back and ask: "hmm... am I reasonably separating my concerns by
putting an add_tag action in my articles_controller? How much
simpler would things be if articles_controller didn't care about tags?".
You don't *need* to subscribe to the whole RESTful or RAILSy way of
doing things. Plenty of great apps don't.
But my advice to you is, if you don't know enough to know the
difference, then don't fight it. It's encouraging you in the
direction of sound software development practices - pointing out ways
where you might separate concerns in your domain logic.