Given arbitrary delays between the two executions; the premise of the test itself is suspect; especially if the allowed time is increased. I think the test is supposed to be testing that the default clock for Instant.now() is the SystemUTC clock.
I'd expect expected to be less than or equal to test.
The use of math.abs allows the clock to go backwards; that might happen if the time was re-set manually.

Thanks @RogerRiggs for the comments. I increased the diff allowance to absorb any compilation related delays. What would you propose here?

If your objection is primarily on Math.abs, is this ok?
long diff = test.toEpochMilli() - expected.toEpochMilli(); assertTrue(diff >= 0 && diff < 10_000); // less than 10 secs

I don't think there is any way to meaningfully and reliably test the assertion that Instant.now() is the using the same clock as Instant.now(Clock.systemUTC()) given the potential delays in execution of the two statements.
It might be possible to ignore well known delays due to gc or compilation by making sure the code is warmed up by repeating the test until the delta meets the .1 sec limit. If it was really a bug, the test would timeout after a couple of minutes. Putting a while loop around the body of the test would cover that.
I'd leave the code using abs alone to avoid exposing some other unanticipated change.

I am keeping the timeout as 60 seconds. is this ok?

    @Test(timeOut=60000)
    public void now() {
        Instant expected, test;
        long diff;
        do {
            expected = Instant.now(Clock.systemUTC());
            test = Instant.now();
            diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
        } while( diff > 100 ); // retry if more than 0.1 sec
    }

Yes, looks fine; The normal JTREG timeout is 2 minutes. 60 seconds is fine for the testng timeout.

FWIW - when I updated the System UTC clock to get sub-milliseconds resolution from the OS I added this test:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/time/test/java/time/TestClock_System.java

Maybe some similar technique could be used here. That is - take System.currentTimeMillis(), Take Instant.now(), take System.currentTimeMillis() again, and then verify that the instant lies between the two snapshots: greater or equal to the first, less or equal to the second. That should always be true (unless the UTC clock is adjusted by NTP). But you could hopefully detect that and retry if you observe that the second call to System.currentTimeMillis() has returned a value which is before the first call.

If the difference between the two System::curentTimeMillis calls is too big, then if you wish you might want to try again too.

I believe this would provide a more robust test strategy.