Nobody's mentioned what I consider to be the biggest problem with this question yet.
I'm talking about the following two answer choices:
The first query returns a Tally table and the second returns the same row count and numbers but in a randomized order.
The second query returns a Tally table and the first returns the same row count and numbers but in a randomized order.
See the problem? They imply that a tally table has to be intrinsically ordered -- this is simply untrue. A tally table simply has to be orderable.
So even if one of the two queries returned its values in a randomized order, it would still be a tally table.
I think that's arguable either way.
It could be argued that to be a table in a relational database a table has to have a primary key; that means there is an intrinsic order determined by the key attributes; a tally table has only one attribute, so it is intrinsically ordered by that attribute.
That's a theory argument. Of course it only applies to base tables and to manifest derived relations (called indexed views in SQL Server), not to other derived relations.
The practical argument is that a tally table, for performance reasons, needs an index on it's single column - otherwise a sort will be required in many cases where if it were ordered the sort would not be needed, so the Tally table would be less useful. But derived relations (other than ordered views) are not ordered, so this argument can only apply when the tally table is a base table (or an ordered view).
Derived tables provided as subqueries (or as CTEs) aren't ordered, just orderable; if few enough rows are required, it's possible that using such a relation as a tally table involves no IO, while using a base table would require IO; and by a happy coincidence (or sometimes by deliberate design) its generation usually happens in the desired order anyway, despite the derived relation not being constrained to have any particular order; so the practical performance argument doesn't work in favour of an intrinsic order in this case. So when a tally table is a derived relation rather than a base table it is reasonable for it not to be in order (and it certainly isn't intrinsically in order).
So whether a tally table has to be ordered or not seems to depend on whether it's a base table (in which case it is ordered) or a subquery (possibly a CTE) delivering a derived relation.
So whether your statement is correct or not depends on whether you call a non-manifest derived relation used in the same way as a (base) Tally table a Tally table or not.