I've checked Unreal source. Problem seems in D3D11RHI module.
There lot of code under IsRHIDeviceNVIDIA() check to handle SLI etc which uses NvAPI_* from nvapi.lib/nvapi64.lib. Even with disabled nvapi it still tries LoadLibrary("nvapi.dll").
If game do not calls FD3D11Texture3D too often disable nvapi approach helps, but if it uses even very simple function often in inner loop - even with disabled nvapi this path can decrease performance.
So nvapi stub or fake AMD card is better solution.

This can be fixed in UE as well. We just can transform checks from

if (IsRHIDeviceNVIDIA())
{
    NvAPI_call()->
    {
        if (!g_lib)
            g_lib = LoadLibrary("nvapi.dll");
        ...call from dll
    }
}

to

static bool GNVAPIChecked = false;
static bool GNVAPIAvailable = false;

bool IsNVAPIAvailable()
{
    if (GNVAPIChecked)
        return GNVAPIAvailable;
    if (IsRHIDeviceNVIDIA() && NVAPI_Loads())
        GNVAPIAvailable = true;
    GNVAPIChecked = true;
}

if (IsNVAPIAvailable())
{
    NvAPI_call()->
    {
        if (!g_lib)
            g_lib = LoadLibrary("nvapi.dll");
        ...call from dll
    }
}

what happens if we just grab nvapi dll's and toss it in the desired path? will it just continue without issue?

Could it help if we'll have nvapi fake-dlls in system32 and syswow64 directories, and nvapi disabled?

Fake dlls can be generated quite simple, e.g. :

$ winebuild -m64 --dll --fake-module -o nvapi64.dll
$ winebuild -m32 --dll --fake-module -o nvapi.dll

Wine looking for requested dll wherever possible before "Load Order" logic will act (see load_dll and find_dll_file).

Disabling nvapi should prevent further searching for builtin nvapi.dll.so, or any actions with nvapi.dll as real dll file, and will return STATUS_DLL_NOT_FOUND immediately.

For UE4 result will be the same, but the way should be shorter.