In practice, the demarcation line for "systems programming" is when the software directly controls and manages the hardware resources it uses. Software like this takes on some of the characteristics of an operating system because it is required to provide similar functionality, even if not an operating system per se. In application code, some other piece of software, usually the operating system, takes care of this for you.

Database engines are an excellent example of this spectrum. Some simple databases contain no systems programming at all whereas advanced databases are essentially complete operating systems that run in user space. If you walk the code bases along this spectrum, you will see a shift in the construction, character, and design of the code base as more of it transitions from "application" to "systems" code.

The distinction is important because systems programming is a different skillset than applications programming. For example, there is often a requirement to do a lot of sophisticated scheduler design that is integral to the correctness of the software in systems programming. Application programming rarely concerns itself with this, it relies on threads, locks, etc and has the OS sort out the scheduling.

Outside of actual operating systems where systems programming is unavoidable, the primary motivation to do systems programming in a user space application is it can greatly improve performance, scalability, and robustness.