The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery.

However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one.

It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc.

If that 70% is too high or low, it can be adjusted.

For everything else, there's Kanban.