A configuration with three voting nodes in different data centres plus an additional non-voting delayed secondary is definitely supported. This is actually a reasonable configuration in terms of satisying core availability requirements using the distributed voting nodes with additional hidden/non-voting nodes for special use cases. A delayed secondary should be always configured as
hidden and priority 0, and may have 0 or 1 vote.
However, there is one important caveat with your deployment: you have three data-bearing nodes but one of those is delayed. This will be problematic if you want to use any write concern higher than the usual default (
w:1 aka acknowledgement by the primary). In the event one of your non-delayed secondaries is unavailable, a higher write concern (eg
w:majority) could still be satisfied but the writes would have to wait for acknowledgement from a second data-bearing node which would have to be the delayed secondary.
A more robust configuration would be to replace the arbiter with a data-bearing secondary so that unavailability of any of the three voting nodes would still allow for acknowledgement of majority writes.