I suspect this has no meaningful performance impact. Some observations which suggest this does nothing:

Locally, bin/repository rebuild-identities --all --xprofile <something> shows <5% of its runtime spent in tsprintf() even with no identities to rebuild (I ran it against phabricator/).

That wouldn't include the echo cost itself, but that looks very cheap. Consider just starting PHP and looping:

epriestley@orbital ~/dev/phabricator $ time php -r 'for ($ii = 0; $ii < 10000; $ii++) {  }'
real	0m0.075s
user	0m0.062s
sys	0m0.010s

...versus printing inside the loop:

epriestley@orbital ~/dev/phabricator $ time php -r 'for ($ii = 0; $ii < 10000; $ii++) { echo "No changes for {$ii}.\n"; }'
No changes for 0.
No changes for 1.
...<snip>...
No changes for 9998.
No changes for 9999.

real	0m0.101s
user	0m0.072s
sys	0m0.019s

So I'm seeing about 25ms of runtime for 10,000 lines of output, or 2.5us/line.

Maybe if you were on dialup this could be blocked on the network, but you could use > /dev/null to fix that.

Based on general experience, I broadly believe console output to be cheap. Historically, the only change I can recall ever making where we reduced console output for performance was D9363, but we were redrawing a relatively more complex progress bar a gazillion times a second there.

Also note that > /dev/null gets rid of most of even the very small cost of echo:

$ time php -r 'for ($ii = 0; $ii < 10000; $ii++) { echo "No changes for {$ii}.\n"; }' > /dev/null

real	0m0.084s
user	0m0.068s
sys	0m0.014s

If there's some evidence this actually does something I'm open to it, but I think this is approximately just an unusual way to write > /dev/null in the unusual cases where it might be useful.