Ugh, I keep meaning to write a blog post that corrects some of the poor formatting and phrasing in that article. And some of the other misconceptions I've seen elsewhere about configuring an NTP time source.
To cut to the chase - there are actually TWO GPOs you need to create. The first one is scoped to the PDCE with the WMI filter and the NTP time source config, as you've done.
The second one is mentioned under Creating a global settings GPO in that article. As says, in a different GPO to the PDCE one, enable Global Configuration Settings under Computer Configuration\Administrative Templates\System\Windows Time Service\Time Providers and you can simply leave the defaults.
This second GPO to enable the "default" time setting needs to be applied in a group policy for all DCs. Ensure the GPO that contains the default time config is a lower precedence than the PDCE one.
Ordinarily, if you have a Default Domain Controllers policy linked to the Domain Controllers OU, you can simply enable the basic Global Configuration Settings for Windows Time in there. The custom GPO for the PDCE takes care of the NTP time config when the role is shifted, and the "default" one will revert the time setting for the old PDCE.
Make sure, of course, that your GPO link ordering is correct in the OU - again, your custom PDCE time policy GPO should have a higher precedence than the default DC policy.
If you want to create a custom GPO linked to the Domain Controllers OU for the default time config, that works too. It's just a little more overhead creating a separate GPO if you've already got a default DC policy. Again, such a custom GPO should also have a lesser precedence than the PDCE one.
I find in the real world, it takes < 5 mins in a well-connected environment for the PDCE to get its new time config (or a GPRefresh to speed it up), while the previous PDCE takes a little longer to revert to the domain hierarchy, depending on the GP refresh time. A slight delay for the previous PDCE to catch up is fine.
