If DR hits, and we have set up log shipping, my guess is that we are only left with whatever the secondary replicas have... That is, if I am able to 'backup the tail' then the server must be up and running...
When logs are restored onto the secondary, the database is being left in "restoring" (or standby as read only) state by restoring logs "with norecovery" option:
RESTORE LOG [YourDB] FROM DISK = 'R:\YourDBLogBackup.TRN' WITH NORECOVERY
If primary is not available
You can always bring it online by running "recovery" command:
RESTORE DATABASE [YourDB] WITH RECOVERY
So if you lose primary, the secondary (DR) will be as up to date as the latest log copied across. However, when you do that manually, you are not going to be able to revert back to primary so only do it when the primary is lost.
Actually, I am going to expand on this.
Log shipping can be as good as any other DR method but it will depend on your RTO (Recovery Time Objective) and RPO (Recovery Point Objective) what method you use.
If you care about every single transaction you will have go with Availability Group Synchronous commit which essentially writes the data first into the DR then into primary.
If, however, you can afford to lose few minutes or even 1 hour worth of data Log Shipping will probbaly be enough. Just make sure you are backing up your log often enough.
The beauty of Log Shipping is that you could even do it via FTP. SQL Servers do not need to see each other for this to work.
If primary is available
The tail backup is only required to do manual failover if Primary datacenter is not lost. You do a tail backup on primary which puts the database into "restoring" mode:
BACKUP LOG [YourDB] TO 'R:\YourDBLogBackup.TRN' WITH NORECOVERY;
You then copy that very last backup file (hence its called tail) and restore in secondary, Bring secondary online and repeat the operation to fail back to primary. You can do it back and forth (fail over and fail back) as many times as you want.