Some AFNI programs do their internal calculations in double precision to maintain accuracy through lengthy computations. 3dDeconvolve and its step-child 3dREMLfit are both in this category. Most other programs operate in single precision ("float") format internally -- including waver -- when there is little or no need for double precision's accuracy (do you need to compute your HRF waveform to 16 decimal places?).

No AFNI programs support saving 3D datasets in double format. If a NIfTI dataset is read that is in double format, it will be converted to float on input. AFNI simply does not support double as a datatype for dataset voxel values. The data types it supports (at various levels) are:
byte short RGB float complex
Not all programs work with all types of input, though -- in particular, relatively few programs will do anything useful with complex-valued datasets.

In the particular case of 3dDeconvolve, there are in fact 2 binary programs made from the same source code: 3dDeconvolve and 3dDeconvolve_f, the latter of which uses single precision internally -- to save memory and for speed. This version of the program compilation was developed at the request of several users (including the [in]famous MSB) who were upset at the slowness of the double version on the pitiful computers they had back then.

When 3dDeconvolve -help says "This version of the program has been compiled to use double precision arithmetic for most internal calculations", that means that you are looking at the -help output from 3dDeconvolve, not 3dDeconvolve_f -- it does NOT mean that there is some older float version -- the float version still exists and is in fact newer than the double version.

There is no single precision version of 3dREMLfit, nor will there be -- that program needs the double precision calculations to ensure stability in the matrix factoring operations it carries out.

I feel that there is some other issue or question behind your question. Would you care to elaborate?