won't that give an error as datediff expects 2 date expressions and you've specified 0 & @dt which is declared as varchar?
Regarding speed, arithmetic operations may be faster than string manipulations but in this case it involves local variables & not table columns so there shouldn't be much difference. If it were on a huge table maybe it could have some impact.
@dt should be declared as datetime, but the code will work anyway as SQL Server implicitly converts date strings.
DateTime values are actually stored as numeric values, which allows you to pass 0 as a parameter to the datediff and dateadd functions.
Whether the variable are local or not does affect the difference in performance between arthimetic and string operations. CONVERT may appear to be a single operation, but its logic contains a loop to process each character of the string, along with whatever logic is required to ensure the result has the required formatting. This is why it is slower than doing a single subtraction (datediff) and a single addition (dateadd).
The difference in speed for single values or small datasets will not be noticable. Hence my statement that the datediff method is faster, but less intuitive. Use whatever method fits your circumstance.
If it's not practically useful, then it's practically useless.