Since the test you are doing is through a ping from router to router, then the problem is most likely related to the fact that you are forcing the CPU to handle all the operations required for this communication.
When you ping between public addresses, the CPU of the spoke will generate the ICMP packet and send it through the best path to the Hub, then the Hub's CPU receives the packet, processes it, creates a response and sends it back. When the DMPVN tunnel is involved, then the Spoke has to create the packet, send it through the best path (tunnel), realize it must be encapsulated (GRE) and encrypted (IPSEC) and do the operations by software, even if you have a hardware encryption module or chip in your router. The same thing will happen on the Hub site which adds to the time it takes for the round-trip of the communication. Also depending on the level of encryption you are using it will take more or less time (DES against 3DES or AES). So by testing with a stream of packets generated and handled by the CPU itself you are not using the advantage of hardware encryption and forcing the CPU to work a little more when the DMVPN connection is used.
Also bear in mind that if at some point the routers have a higher CPU utilization due to something else happening on the network, this same test will show an even bigger delay because the CPU is already busy handling some more important operations than encapsulating and encrypting an ICMP packet.
A better test might be to send a ping from a device behind the Spoke to a device behind the Hub, so that the hardware encryption and CEF takes place to deal with the packets in a faster way.
