I would say that the common feature of a systems language is that it is explicitly designed to enable direct control of hardware resources and -- very important

I would say that the common feature of a systems language is that it is explicitly designed to enable direct control of hardware resources and -- very importantly -- operation scheduling by the programmer. A point I think is often overlooked is that some software architectures cannot be implemented correctly without this level of control, and for some applications those architectures are the only competent choice. Using a systems language should be driven by the requirements of application with respect to software architecture, and most applications don't have that requirement. Some applications that are above the OS and device drivers, such as database engines, are clearly in the domain of systems applications because it is not possible to create a competent implementation without the control a systems language provides. Even for relatively abstract high-level software like distributed systems, strict control of scheduling is required for consistently robust throughput and behavior. Some key algorithms only work in real systems if resource management and concurrent operation sequencing is inexpensively deterministic. For some other applications, the only real benefit of a systems language would be for performance engineering purposes, which may not be a practical priority. The "managed language" litmus test is quite good in my opinion, and almost definitional.