You are comparing a column value to signed in user, so it’s looking for a match in that column. Otherwise with your original thinking, there would be no point to compare to a specific column. It would need to check if the user is signed in or not (there is no such check).
As for benefits, that depends on your use case. Bringing in emails from App:Logins eliminates a step for the user by automatically creating user specific rows, but you run a risk of emails shuffling around if you use the Unique formula and delete or sort the records in app:logins. If info is personal, you do not want to run the risk of the unique formula reshuffling the emails and creating mismatched data for each email.
Using the email special value is better, but the user has to first submit a form to create their own user record by writing the email special value to the sheet.
There are scripts you can use to write new user emails to a sheet. I use one to similarly copy new names to several other sheets. This automates the process and eliminate the user needing to submit a form, but complicates things by introducing a script.
Ultimately you shouldn’t need any of this once user specific columns are released, but I don’t know when that will be. I’m hoping within a few weeks. In that case we’ll be able to store values from several users in a single row cell.
In the end you pick what works for you. Many people have began creating user specific rows by submitting a form with the email special value.