A lot of these are pretty similar to the restrictions built into the IEC 61131-3 'Structured Text' programming language (https://en.wikipedia.org/wiki/Structured_text). It's basically just removing things that commonly cause problems.
Fancy language constructs and complex algorithms are generally not helping. Keeping the program simple helps verification using automatic tooling and manual code reviews because the risk of hidden side effects or undiscovered defective code paths is minimized.
More precisely, however, heap allocation is usually accepted during the initialization phase (the moment when you can still abort the process with no consequence if needed, i.e in the case of a rocket, before it takes off).
These guidelines aren't meant to be applied for "general-purpose" code, which may be used by a human operator in a million possible ways. It's usually very special-purpose code that does only a handful of things (and if it doesn't, that's meant to be treated more like a design problem than anything else). Consequently, it's not that hard to figure out how much memory you need from the very beginning, and not allocate any of it on the fly.
Allocating memory on the heap complicates analysis a lot. It introduces potential timing issues. You have to make sure that no matter how your program runs, it'll always be able to allocate the memory it needs -- or to design it so that it runs correctly (i.e. predictably and in the right manner) even when an attempt to allocate memory fails. You have to bring in pretty complicated third-party code, or spend a lot of time and money writing your own (writing a memory allocator is trivial, but writing a good, safe one isn't exactly a walk in the park).
As for function pointers... that's more or less the same story. You don't need them that often for this sort of code, and when you do, the trade-off is usually worth it.
(In very rare situations it's not, but IMHO coding standards do the right thing here. Judgement calls about these things are very much subject to ego and organization politics. It's always better to err on the side of having to do extra work under some circumstances).
These guidelines don't produce the most good-looking code but they do make it harder to shoot yourself in the foot.
Obviously, there is an argument to be made about alternative solutions, such as code that you cannot physically point at your foot, but that's a discussion for another time (and also way more complicated than that...)
In the PLC / industrial automation world there's the added consideration that your code will probably need to be maintained (or at least navigated and understood) by people with limited software skills. And given that systems tend to be "wide, not deep" (as in, hundreds or thousands of mostly-independent inputs that only interact via very simple logic), usually ladder logic or function block diagrams are the preferred way to implement these sorts of systems. Even Structured Text is considered a bit too technical by most people.