I personally like that construct, but AFAIK it's rather unusual in KDE code, so maybe for the sake of the future developer use something more "classic".
Either:

const auto name = d->applications[i].name;
if (d->applications[i].blocked) {
    blockedApplications << name;
} else {
    allowedApplications << name;
}

Or:

auto &list = (d->applications[i].blocked ? blockedApplications : allowedApplications);
list << d->applications[i].name;

Second option is closer to your initial intent (I think it's still less common than the first, but at least we guide the future reader understanding with the intermediate variable).

It shall work as intended for now, but I think there's a potential caveat there in case of future refactoring and if the timing between save()/load() of the various settings object change. The isSaveNeeded()/isDefaults() state will be based on the whole settings object state. So we might claim here for saving being needed (currently unlikely AFAICT) or settings not being defaults (currently likely if load() brought values from the file which weren't defaults) based on config keys which are not managed by this class. I thus wonder if it wouldn't be wise to restrict that to only the items concerned.

You should be able to connect directly using the function pointer style connect and spare the existence of onChanged and onDefaulted.

I think I'd make the name of those signals more explicit. The tab is mostly working as a regularly managed thing, except for the model. So maybe just prefix with "blacklist" like:
blacklistChanged(bool) and blacklistDefaulted(bool) ?

To reduced code duplication and make sure we're not uncontrollably getting in null pointers land, I'd use intermediate variables for the item pointers and I'd throw a bunch of Q_ASSERT:

auto blockedAppsItem = d->pluginConfig->findItem("blockedApplications");
Q_ASSERT(blockedAppsItem);
auto allowedAppsItem = d->pluginConfig->findItem("allowedApplications");
Q_ASSERT(allowedAppsItem);