Explanation for second Compute Scalar
There's nothing particularly interesting about the number of Compute Scalars. The compilation and optimization process often produces more of these than is strictly necessary. Conor Cunningham talked about this in general terms at one of the early SQLBits conferences. In an ideal world, unnecessary scalar computations would be collapsed at the end of optimization, but only a few cases are implemented.

On the background: the choice of Flow Distinct depends on the number of rows needed being less than the number of distinct values estimated.

Using a variable with TOP means a default guess of 100 rows needed, so we need the number of distinct values to be more than that.

How the cardinality estimator (CE) treats ABS(CHECKSUM(NEWID())) depends on version. The CE model introduced in SQL Server 2014 estimates this expression will produce one unique value, regardless of the number of times it is evaluated (number of Numbers table rows read in this case). This is not a very good estimate of course.

The pre-2014 CE model makes a better educated guess, giving an estimate well in excess of 100, and so a Flow Distinct. My Numbers table does have ten million rows though. You can help the equation along if necessary by hinting a low value for @t e.g. OPTIMIZE FOR (@t = 1).

You can hint the earlier CE model in any of the usual ways e.g. USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION') or USE HINT ('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110').

For example:

DECLARE @T integer = 3;

SELECT DISTINCT TOP (@T)
    ABS(CHECKSUM(NEWID()))
FROM dbo.Numbers AS N
OPTION
(
    OPTIMIZE FOR (@T = 1),
    USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110')
);