I am most definitely thinking of the children when I implement such features.
Indeed the clipboard is not restored specifically because it would be dangerous to do so and lead to problems that are complex in nature.
There is a large descriptions of the issues suroudning it in the FAQ Why is the clipboard not restored after any clipboard action?
It all relates to the intricacies of the the event queue, which means that UI events (such as key presses and mouse clicks and especially the ⌘V that Keyboard Maestro simulates to cause the Paste to happen) are placed in an event queue, which is then processed at a later time by the OS and then the current front application. Meanwhile the clipboard is set by explicit APIs that happen without delay. As such, the clearing of the clipboard to restore the previous clipboard has to happen after some period of time, which length is unknowable in practice. If it is done too soon, then the wrong clipboard will be pasted when the system and application eventually get around to processing the ⌘V. If it is done too late then you could potentially have Copy or Cut other information, which would then be destroyed.
So by all means, ignore the fate of the children and delete the clipboard immediately after the Insert Text by Pasting, Keyboard Maestro will not stop you doing this, but it also will not actively help you set yourself up for problems by adding an option to do this.