The kwriteconfig still affects the Plasma setting for “Default Applications” – how much that does anything more than the MIME settings – it is probably relevant for some use cases, though none come to mind at this point. If kwriteconfig5 does not work for you, you can try using kwriteconfig6 (though the KXMLConfig framework’s file format hasn’t changed and from my experience kwriteconfig5 does not cause issues with Plasma 6 – at least not in this use).

As for slowness – on my system xdg-settings takes 0.5s to run and xdg-mime takes about 0.2s. But more than that – I’m not sure what delay is of an issue here: the setup described in this post is about running a standalone service that monitors events and acts independently – it does not block any Plasma operation so any slowness in the script shouldn’t affect behavior, except for maybe that the browser change will not take effect immediately after an activity change – so if you get into the habit of positioning your cursor on where a link would appear on the next activity, then switching and immediately clicking the link – that could be a problem, though I don’t think that this use case is reasonable. Also – I’m not sure about the logging issue: the writeconf function is the last thing executed in the monitor loop and it doesn’t do any logging. Generally I wouldn’t recommend running the file modification commands in parallel – as they all basically modify the same files and you don’t want to get into multiple commands modifying the same file concurrently – they either know how to handle this well (using file locking), in which case you gain almost nothing, or they don’t – and you get corruption.