It's certainly useful for the code to be expressive. But sometimes it's more important for the code to be easy to analyze and easy to verify than for it to be expressive and/or concise. I know that the mantra goes that "concise code is easier to analyze" but that's not always the case. It's true that "concise" code is usually easier to "match against" an algorithm -- i.e. it's easier to read the code and figure out if it does what it has to do. But you also have to reason about whether what the runtime does behind the scenes is correct or not, and your reasoning has to exhaust every scenario. If the runtime offers no such (or very few) guarantees, "expressive" code is very hard to deal with.
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...)