During the runtime I replaced the 32bit app by the 64bit app making the task think it's still running the 32bit version.

32bit part:
[09:22:40] INFO: Checkpoint taken at 2019-02-10_06:00:00
[11:23:29] INFO: Checkpoint taken at 2019-02-10_12:00:00
[13:26:48] INFO: Checkpoint taken at 2019-02-10_18:00:00
[14:59:45] INFO: Checkpoint taken at 2019-02-11_00:00:00
64bit part:
Starting WRFMain
[16:14:11] INFO: Checkpoint taken at 2019-02-11_06:00:00
[17:49:19] INFO: Checkpoint taken at 2019-02-11_12:00:00
[19:25:05] INFO: Checkpoint taken at 2019-02-11_18:00:00
[20:24:10] INFO: Checkpoint taken at 2019-02-12_00:00:00

I know it are sequential days, but it is a remarkable speed-up.

Another thing I noticed since the start of the project, is that the 4th and 8th part of a task (so the period between 18:00 and midnight are mostly faster.
With my meteorological background, I conclude that in the sub-Sahara most rain will fall in the period between 12:00 and 18:00 UTC
and therefore processing the data from those periods are lasting longer.

If you want to avoid 32 bit apps, best to use <no_alt_platform>1</no_alt_platform> in cc_config.xml then restart BOINC, so will not receive 32 bit app, and the server will know this by refusing to send 32 bit apps.
Just a warning, possible invalids. Both 32 bit and 64 bit can make slightly different calculations which can cause invalids as results don't exactly equal. Mostly depends on how verify works. Verify is possibly just a simple check, data exacly the same. This might be a reason why all tasks in one work unit is either 64 bit app only or 32 bit app only.

Also, BOINC exit and restart will delete and re-download to the proper app/file if filesize is different, unless BOINC config <dont_check_file_sizes> was set to 1.

The use of 80 bit float can slow down 32 bit app. Here is a wall of text that some programmers will know:
My guess is, something to do with only 32 bit app (not 64 bit) use a higher precision 80 bit floating point registers, but store them as 64 bit or 32 bit float on parts of the compiled binary code. Also, fewer registers (8 vs 16), this can slow things down. Can minimize this different calculation issue if 32 bit app was compiled with SSE2 instruction set. GCC compiler can use -msse2 -mfpmath=sse to use 32 bit and 64 bit float registers. 64 bit compiler already use SSE2 with no option neccessary, as all 64 bit AMD64 intel64 have SSE2 instruction set. There is also -mpc64 or -mpc32 to tell the 80 registers to operate as reduced precision, but unfortunately it is not easy to handle mixed 32 bit and 64 bit float unless SSE2 is used.