Multiplayer is one of the most complicated features - even making small changes can be very difficult, and it's particularly time-consuming to test. Host migration in particular is extremely complicated - it would have to transmit the entire state of the game to a different peer, and then your events would be super complicated too, as you have to switch over the new host from peer mode to host mode, switch over all other peers to recognise a new host, and if at any point you get it wrong things will go haywire, and you'll face similar issues with the high complexity of multiplayer logic and the very time consuming and difficult issues that come up in testing. (For example a typical issue would be: about 1 out of 10 times in host migration, you end up with the wrong groups activated and the game doesn't work, and it's an absolute nightmare trying to figure out why.)
I think the main issue with the Multiplayer object in Construct is the forbidding complexity of multiplayer logic is generally a poor fit for a simple, no-coding tool that generally attracts non-technical users. You have to think about multiple copies of the game all running simultaneously, but all on slightly different time delays, with an authoritative host and thin-client peers running various kinds of prediction to hide lag. It's a lot to ask for people who are new to all this. On top of that we are a tiny team (we have just 3 developers, and some competitors have dozens or even hundreds), and it is such hard work to develop multiplayer features that it carries an enormous opportunity cost as we'd basically have to cancel a bunch of other feature requests to do even one multiplayer update. So in the end working on multiplayer is a low priority. As it stands though it's still pretty good for small casual games without needing to set up any infrastructure, which I think is a decent fit for the type of tool Construct is.