Iliara,
I would not consider myself an AFNI expert, but I would not recommend "mixing and matching" these preprocessing pipelines, as neither of them are designed to interoperate. fMRIPrep is intended to replace all other programs' preprocessing, by doing the "mixing and matching" between major packages for you. If your plan is to do a GLM, etc. in AFNI then I would recommend just using afni_proc.py. There are many subtle sorts of errors (see below) that can be introduced if you're not very careful.

1. Yes, the order is relevant. See the 3dvolreg help under "-dfile": [afni.nimh.nih.gov]
> n roll pitch yaw dS dL dP rmsold rmsnew
2. Yes, any ASCII text matching AFNI's specifications for a regressor should work; see, for example, the help for 3dREMLfit: [afni.nimh.nih.gov] (unless you mean to censor motion, in which case it's probably easier to manually specify volumes that you would like censored in 3dDeconvolve; see -CENSORTR)
3. Sorry, I'll have to wait for somebody else to answer that.
4. Additional regressors will not impact motion censoring.

For slice timing, the note in 3dTshift points out how the timings affect operations like 3dDeconvolve: [afni.nimh.nih.gov]
> The new slice/volume timing is intended to be the real timing from the
start of the run.

> How might this affect stimulus timing in 3dDeconvolve?
3dDeconvolve creates regressors based on volume times of k*TR, matching
tzero=0. So an event at run time t=0 would start at the time of volume
#0. However using -tzero 1 (or the default, in the case of TR~=2s),
an event at run time t=0 would then be 1s *before* the first volume.
Note that this matches reality. An event at time t=0 happens before
all but the first acquired slice. In particular, a slice acquired at
TR offset 1s might be unaffected by 3dTshift. And an event at run time
t=0 seems to happen at time t=-1s from the perspective of that slice.

> To align stimulus times with the applied tzero of 3dTshift, tzero
should be subtracted from each stimulus event time (3dDeconvolve
effectively subtracts tzero from the EPI timing, so that should be
applied to the event times as well).

It is not clear to me if fMRIPrep would make the same guarantees as 3dTshift (representing a possible interoperability issue).

However, 1s is pretty short, you may use slice time correction but it may not make much of a difference.