This is is related to enterprise settings:

If the identity.fxaccounts.enabled pref is false, we shouldn't be showing FXA snippets at all:

https://searchfox.org/mozilla-central/source/browser/components/enterprisepolicies/Policies.jsm#312

(this might be covered by our targeting already just filing to make sure)

This patch will add a new targeting attribute that checks if FxA services are disabled.
Snippets that use usesFirefoxSync should be updated. My suggestion would be:

// This way we don't have to worry about targeting specific versions that have the attribute
usesFirefoxSync && (isFxAEnabled == undefined || isFxAEnabled == true)

(In reply to Andrei Oprea [:andreio] from comment #2)

This patch will add a new targeting attribute that checks if FxA services are disabled.
Snippets that use usesFirefoxSync should be updated. My suggestion would be:

// This way we don't have to worry about targeting specific versions that have the attribute
usesFirefoxSync && (isFxAEnabled == undefined || isFxAEnabled == true)

Can we apply this new JEXL now, without affecting the behavior in older versions of Fx?

Yes, if we ignore when the attribute is undefined it should not affect older version of Firefox.

https://hg.mozilla.org/mozilla-central/rev/5c4931404035

The issue is not actionable right now, because the only snippet present in Nightly is the "Special FxA" one (displayed under the in-content Search Bar) that has no targeting parameters set and is displayed on each New Tab page regardless of the "identity.fxaccounts.enabled" pref's value. Considering this I will leave a ni? on myself in order to verify this issue later.

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (68.0a1 Build ID - 20190509033505) installed, on Windows 10 x64, Arch Linux and Mac 10.13.3. Now, the "Special FxA" snippet is no longer displayed if the "identity.fxaccounts.enabled" pref is set to false.