Looking at your first screenshot (I have never used this software myself), it appears that the first A e14.whatsapp.net query has been made at millisecond 190, the next at 218. There have been only 28 milliseconds in between and your unbound may simply not have been quick enough to reply. The reply then arrived at 218+21 = 239 so 49 msec after the initial attempt. Not bad at all I'd say when this wasn't in unbounds cache.
I see four possibilities (roughly sorted from worse to best):
Use FTL's internal cache with the new option use-stale-cache (details here), and/or,
Make sure unbound is pre-fetching these queries, and/or
Simply accept this happening, it isn't a Pi-hole nor an unbound issue, or
Get in touch with the developers of this application and have them fix this misbehavior (best option!)
I assume this is basically the same unbound + redis does, origininal topic here. Have been using that solution for a long time, without any negative experiences.
Have you tuned your operating system to use extremely small DNS timeouts or does it even lack its own DNS caching? That seems to be the only option (well, besides a bug, of course) for these observations.