Hi-

OK, so that shows why they have different 'space' properties: the sform_code = qform_code = 2 for your EPI, while sform_code = qform_code = 1 for the anatomical. I am not sure why that software outputs these final datasets with different values for these codes (presumably they should overlap at that point, even if they have different grids/voxelsizes?).

What do {s,q}form_code values do? They are supposed to tell whether the dataset is in native or standard space. Scrolling down in the NIFTI code here:
[raw.githubusercontent.com]
... you will see that each of these can take one of the following integer values:

/* [qs]form_code value:  */      /* x,y,z coordinate system refers to:    */
   /*-----------------------*/      /*---------------------------------------*/

/*! \defgroup NIFTI1_XFORM_CODES
    \brief nifti1 xform codes to describe the "standard" coordinate system
    @{
 */
                                    /*! Arbitrary coordinates (Method 1). */

#define NIFTI_XFORM_UNKNOWN      0

                                    /*! Scanner-based anatomical coordinates */

#define NIFTI_XFORM_SCANNER_ANAT 1

                                    /*! Coordinates aligned to another file's,
                                        or to anatomical "truth".            */

#define NIFTI_XFORM_ALIGNED_ANAT 2

                                    /*! Coordinates aligned to Talairach-
                                        Tournoux Atlas; (0,0,0)=AC, etc. */

#define NIFTI_XFORM_TALAIRACH    3

                                    /*! MNI 152 normalized coordinates. */

#define NIFTI_XFORM_MNI_152      4

                                    /*!  Normalized coordinates (for
                                         any general standard template
                                         space). Added March 8, 2019. */

#define NIFTI_XFORM_TEMPLATE_OTHER  5

So, a value of 3, 4, or 5 will be recognized by AFNI as a standard space, by definition---those will get "+tlrc" in BRIK/HEAD names. A value of 1 will be recognized as non-standard, or subject, space---it will get "+orig" (as I think a value of 0 will. However, the case of a value of 2 is ambiguous---I think our preference would be that software never output that value, *because* it is ambiguous as to whether the dset is in standard or some subject space.

There is actually an environment variable to control this ambiguity how you wish. It is described here:
[afni.nimh.nih.gov]
... as:

AFNI_NIFTI_VIEW

    The default view extension used for output when creating AFNI format
    datasets from NIFTI datasets.This variable is only applicable for
    sform and qform codes that do not have clearly defined views
    (sform/qform code = 2). Set to "tlrc" or "orig". See also
    AFNI_DEFAULT_STD_SPACE and AFNI_NIFTI_PRIORITY. Note sform/qform code=5
    can be used for spaces other than MNI or TLRC including MNI_ANAT or D99
    spaces.

So, sorry about the long post, but to summarize:
+ your EPI and anatomical come out of FMRIprep with differing {s,q}form_codes. I am not sure why this is the case, since these dsets should overlay well, assuming they are both the final EPI and anatomical dataset. Maybe someone else can answer that.
+ The {s,q}form_code of the anatomical is 1, so AFNI recognizes that directly as "orig" data.
+ The {s,q}form_code of the EPI is 2, which is unfortunately both different and ambiguous. Right now, the default on your system is to interpret it as "+tlrc".
+ You could choose to have an {s,q}form_code of 2 be interpreted as "orig" by setting the above environment variable in your ~/.afnirc or in your script for copying the NIFTI -> BRIK/HEAD. To do this in your ~/.afnirc, that would be:

AFNI_NIFTI_VIEW = orig

--pt