Imagine example.com as your public facing brand and where your product is presented and sold. You probably have some kind of sales flow, maybe a product portal, etc. They all live wonderfully either as subdomains (e.g. signup.example.com) or sub-resources (e.g. example.com/signup).

Behind the scenes you probably have some cloud hosted resources for the website, product portal, some kind of admin portal, and some physical infrastructure associated with all this. You probably also have internal tools: Jenkins, Sentry, GitLab, misc home brew apps, etc. You'll save yourself all sorts of trouble putting this behind a "service" domain (e.g. example.net).

- Customer facing URLs always have prime choice of URLs that will never conflict with usage elsewhere

- SSL certificates can be managed independently with much greater ease

- Delegating DNS responsibility (essential for automation) becomes much easier

- You'll almost certainly be moving components around (e.g. your site, how your host your backend, extra goodies like a blog). This makes it easier to keep example.com URLs simple and intuitive. Your "service" domain is likely to be much more literal in its organization of resource records, as it's likely to have lots of mappings to specific, real things.

There isn't a security benefit, but every time I've seen this rule violated it causes pain at some point.