The rule about pointer is pretty limiting (no pointer function, no more than one level of dereferencing).
The reason is also pretty sad : "Pointers are easily misused, even by experienced programmers". I don't see how an experienced programmer has more chance to misuse pointers than anything else.
I believe this is because of the type of code they write. When writing real time systems you care about predictability of execution. When you allow function pointers, you (as a programmer / static analysis tool) suddenly have no idea what code will be executed, thus you can't reason about the time it takes. You could scour the codebase for all instances of code that set a particular function pointer, but then again it might be done indirectly, or - heaven forbid - based directly on external input. It makes code much harder to reason about.
This. There are categories of embedded system that don't allow reentrancy; it must be possible to represent the program's callgraph as a DAG with each function appearing exactly once. In some systems (ADA?) this allows for the preallocation of all local variables, too.
Some hardware (e.g. the smaller PICs) has poor support for pointers which can make indirection cost quite a lot of instructions.
Then there's the general principle of cutting your coat according to your cloth. You don't use a generalised pointer-to-rocket-engine system because you aren't going to add more engines at runtime
The problem is really the redirection. The guiding principle of this document is wrapping every single functional block in a self-contained, statically-analyzable function.
If there is anything that pointers must be used for, then they must be used. But it is hardly controversial to say that pointers are one of the least-well understood and frequently misused aspects of low-level programming.
I wouldn't say pointers themselves are not well understood. The concept itself is painfully simple. The problem is that code that abuses pointer tricks can very quickly become poorly understood. For the type of software JPL writes, they'd rather sacrifice a bit of speed for easily verifiable correctness. My reading of this document is that they treat pointers like Java (and others, of course) treats references, conceptually.
Imho, it's less to do with "misusing" pointers at the micro level and more to do with the macro level effects of pointer dense code. Of course, if you're not allocating or freeing any memory after initialization, then you avoid many of the risks... but structural spaghetti that can hide bugs can still ensue.
The reason is also pretty sad : "Pointers are easily misused, even by experienced programmers". I don't see how an experienced programmer has more chance to misuse pointers than anything else.