Same reason why you would split large modules in your regular code base: maintainability & navigability.
Over time as your step definitions grow you will have steps that are closely related to certain parts or functionalities of your system, but not related to other steps in the step definitions. Once the file becomes large enough it will become harder ...
Katalon has an example project on github: https://github.com/katalon-studio-samples/katalon-bdd-cucumber-tests
Although I find the directory structure hard to navigate the feature example does follow a pattern like:
Feature file (feature code example)
Steps that use test cases in pages (steps code example)
Pages that implement actions (page action example)
I personally divide the logic into three levels:
feature file (Cucumber),
step definition (Cucumber + Java),
page objects (Selenium and Java).
Cucumber separates business logic from the programming logic (1. and 2.) and the page object pattern separates test methods from the pages locators.
Gherkin should also be devoid of technical details. The fact the notification setting is saved to the database does not belong in a scenario. The fact notifications are turned "on" does belong. I would just change the wording in your Then step to:
Then email notifications should be on
Also notice that "email" is all lower case, since it is not a proper ...
You can simply add a commented line if it's better for understanding the scenario.
Otherwise you can alway add an empty step, even a generic one like "Business Context:...." to reuse that empty step for multiple purposes.
To cope with the complexity and ease of maintenance.
Once we reach a size where it becomes difficult to maintain a single step definition file, then we split generally based on per page object however as we need to maintain state, we need to create global objects like webdriver and page objects and share the reference of the objects between files.