A thought provoking read is What is Systems Programming, Really? (http://willcrichton.net/notes/systems-programming/).
I've dabbled on the idea of low level vs high level programming languages before. You have to wonder what is the limit for high level vs low level and I think this post approaches it well. The author noted that several contributors to lower level languages when asked this question: "what is a systems programming language in 2014?" that they generally agreed that the language must offer you a way to get to the binary bits of data and to instruct the machine on how to process the data precisely.
Memory Allocation: Think about it, memory allocation is generally not something one writes in a high level language. Who wants to think about how bits in memory are set, accounted for and shifted while trying to serve a web page, so clearly memory allocation must be a low level attribute. I cannot agree with this since one can write a memory allocator in any language. I would agree one had said you could tell the OS how to allocate memory instead of the runtime. In my opinion, it is generally a time suck to write one since whatever you write will be slower/impractical though one should not be discouraged from learning about memory allocation as it could be useful skill for an unforeseen circumstance!
Pointers: The ability to forge numbers into memory addresses sounds like a low level language attribute. Sure I'll go with this. It is hard to argue that this does not give you preciseness.
If someone had said "Java is a high level language because you can't natively turn
numbers into pointers" I would say you are wrong and should look again
what you can do in Java as you have only used the high level apis. It just takes a lot more thought on how to work with native memory in Java.
Client side applications: This one I think is a cop out. Seriously? C/C++ is used to code client side applications. Go can be and is used to write client side applications. A terminal is a client side application! Come on.
Stuff that runs in the cloud: So much wat on this one.
Operating systems writing language: but you could write an OS in many languages. It would just be impractical and/or a time suck to write one in an scripting language like PHP or Ruby. You could certainly write an OS in Java without using GC, but why?
Resource management: Erm, hmm.. "finer grained control... Running out of time... memory" I guess this means real time language where you can suck all the CPU you want sort of like avionics. Sure I'll agree with this one. It is in a gray area for me though.
What is systems programming then?
I think it is the act of micromanaging the machine. It is just an activity that you can perform in your application. The minute you use any language that allows you to directly tell the OS or hardware strictly what you want it to do. You can instruct the OS to not manage this resource and you will manage it yourself in the application. Ability to talk to device drivers directly is one systems programming attribute.
The article talks about some of the "blurring" between high and low level languages. I think the problem is that we've try to cleanly separate languages into high level from low level, but in fact some languages offer varying levels of the spectrum. Language as an abstraction of the machine but offers ways to perform varying levels of activity whether it is memory management or presenting UI to a user.
Game programming requires a lot of systems level activity, but it is still an application.
You could ask me today, why did I choose Typescript, Java and Rust as my primary languages. It all comes down to abstraction, how easy it is for me to do certain activities with the tradeoff of performance.