I have accidentally made some progress on this.

The underlying cause of the problem is still unknown and unresolved, and I am nearly convinced that it is internal to EMDK 3.0 U1 or the (Android 4.1.2) TC55 device. However, in an attempt to intercept the issue and display useful feedback, I discovered that repeating the attempt to acquire the scanner often (always) succeeds. Since I don't actually use the AsyncTask pattern but executors I won't be building on the code samples included in the original post.

In EMDKManager.EMDKListener#onOpened, and later on in Activity#onResume, I call #acquireHardwareScanner():

private void acquireHardwareScanner() {
    if (scanner != null) {
        return;
    }

    if (BuildConfig.DEBUG) {
        checkState(barcodeManager != null, "barcodeManager == null");
    }

    synchronized (lock) {
        if (scanner == null) {
            final Scanner s = scanner = barcodeManager
                    .getDevice(BarcodeManager.DeviceIdentifier.DEFAULT);

            if (s == null) {
                throw new RuntimeException("Null scanner returned");
            }

            s.addDataListener(this);
            s.addStatusListener(this);

            scheduleScannerAcquisition();
        }
    }
}

private void scheduleScannerAcquisition() {
    if (BuildConfig.DEBUG) {
        checkState(scanner != null, "scanner == null");
    }

    final ListenableFuture futureScanner =
            scannerExecutor.submit(DefaultScannerPreparation.of(scanner));

    Futures.addCallback(futureScanner,
            new EnabledScannerUICallback(this),
            new MainThreadExecutor());
}

DefaultScannerPreparation is a Callable that makes calls to #enable(), #getConfig(), and setConfig(ScannerConfig); it returns an Optional.

I use Guava's Futures to schedule a FutureCallback. This can be done using plain java.util.Futures, but it's more boilerplate and I already had a dependency on Guava.

The callback's onSuccess(Optional) is uninteresting; it only arranges some fragments. onFailure(Throwable)looks like this:

@Override
public void onFailure(@NonNull final Throwable t) {
    if (BuildConfig.DEBUG) {
        t.printStackTrace();
    }

    final MainActivity main = weakMainActivity.get();

    if (main == null || main.isFinishing()) {
        return;
    }

    if (++consecutiveAcquisitionFailures % 3 == 0) {
        allowUserToBail(main);
    } else {
        main.scheduleScannerAcquisition();
    }
}

The most important part here is the call to #scheduleScannerAcquisition(), which submits another attempt to acquire the scanner in nearly the same way. The only difference is that it skips the preliminary setup, including the call to BarcodeManager#getDevice(BarcodeManger.DeviceIdentifier) and the calls to #addDataListener and #addStatusListener.

To test this, I manually put the device into the problematic state using the method explained in the original post. The situation now is that the first attempt to acquire the scanner, whether it be called from #onOpened or #onResume, always fails, and always in the same way as mentioned in the original post. The automatic retry then succeeds, and I have no further trouble interacting with the scanner. This sequence will repeat itself whenever the app is brought into the foreground until I reboot the device.

I have not yet experienced a failure streak of 2 or more. That is to say, the first retry always succeeds. However, I have very little data so far, so I built in a failsafe that prevents a possible lock.
I have confirmed with certainty that the problem is not directly caused by any of #getDevice, #addDataListener, or #addStatusListener, nor the timing of them. If they play a role in the issue, everything suggests that this is not in userland.
I have not investigated whether delaying #acquireHardwareScanner() makes the underlying issue disappear.

I am still interested in knowing why this happens and if it can be avoided completely, but so far this work-around seems usable.