The purpose is to avoid unnecessary work by forcing the user/customer to supply a solid, tangible business benefit as a reason for the existence of this feature.
It is not unheard of that features get added just because someone thought they sounded cool, or because other software has it, so ours must have it, too. More often than not, those are at least completely unneccessary, if not actively harmful.
However, it is usually easy to spot those features, because the people proposing them generally will have trouble supplying a convincing business reason for them.
There is a technique called Popping The Why Stack, where you take the "so that" part, and ask "Why?", then you take that answer, and ask "Why?" again, recursively. If, after (let's say) three to five "Why"s, you have not arrived at either "because it'll make us money" or "because it'll save us money" (preferably with a precise description of exactly how that is going to happen), then the feature isn't worth implementing.
Some people believe this to be so important that they actually put it first in the story template:
In order to [...]
As a [...]
I want to [...]
There's a great example from a talk by some Thoughtworks people: one of their clients wanted the printed reports formatted in a very peculiar way. When the consultant asked "Why", they said that that way they were easier to type back in. So, instead of implementing the report formatting feature, they just transferred the reports over the network. Without the "so that" clause, they would still be printing theose papers out in one department, mailing them over to the other department and typing them back in.