Sprint-spanning stories are problematic for several reasons. First of all, it is obviously a good goal to plan your sprint such that you can finish it by the end - else there would be little reason to have the sprint structure at all, and you could just employ a flowing Kanban-style process. That said, I have worked in projects which had a more relaxed stance on this, and it was OK - if and when all people involved, including product owner and stakeholders, were aware with it, and if it was acceptable to all of them. The projects felt more like Kanban projects, but used all of the SCRUM artifacts (dailies, planning, review etc. sessions).
A second reason to avoid long-running stories is if your single project is related to other agile projects, for example in the context of a SaFE or LESS-based larger environment. In this case, it is quite critical that the individual projects have synchronization points, especially if there are technical interfaces between the applications.
Coming back to the project itself: in one of my projects we don't even plan stories which would load one person fully for the sprint duration, but we limit ourself to stories which would load one dev for half of the sprint (per story). The reasoning here is that if we have a story so large often is an indication that it is not designed correctly (unclear requirements, too large interdependencies etc.). By forcing ourselves to cut it smaller, we really force ourself to be clear on the reqs, and also make it possible to work in parallel, if at all applicable.
Also, if and when an unplanned showstopper occurs for a very long-running story, you might not have another good story to work on in the sprint (because you planned for one dev-capacity to be completely blocked by that one story). This also reduces your flexibility. If you only have smaller (independent) stories, it makes it much easier to switch work to another one, for the affected developer.
Having smaller stories makes it more likely for another dev to take over, if one of your colleagues becomes ill or otherwise unavailable.
Finally, being able to finish a story is always a great feeling for a developer. Having more stories means having more of these events - always a good thing! This really creates a gamification situation where people (aside from producing useful products) also enjoy ticking of lists. For some, this is definitely a motivator (compare with all the personal time management systems like GTD, bullet point lists and such).
Of course you always will have larger feature sets which you simply cannot finish in one sprint. There are the "Epic" or even "Saga" mechanisms for this, where you have a bracket to track long-running implementations.
TLDR: So there you have it. There are plenty of good theoretical and practical reasons for having smaller stories, and I know of none to have larger ones.