Since you're staying with 2008R2 (both source and destination) there is nothing stopping you from just backing up and restoring all of your databases including the system databases. As Shanky pointed out, this would save a great deal of time:
1) Backup and Restore Databases - Is this the best option?
It's an option. If you need the downtime to be less, you can use mirroring or log shipping (or do it by hand) to keep the databases in sync and then migrate during a fast downtime or cutover.
Please note that system databases cannot be log shipped or mirrored and would need to either be frozen or copied right before the cutover.
2) Migrate Logins - use Microsoft KB? kb/918992
If you restore the master database to the new instance, no migration should be needed. All server level logins are stored in the master database.
3) Migrate Credentials/Certificates - what is required for this?
If this is inside of SQL Server, these would be held in their respective databases (and possibly master as well). The one difference would be the service master key (SMK) that would change. You make want to back that up and restore it on the new server if you're relying on automatic key decryption.
4) Migrate SQL Server Agent Jobs - (Object Explorer Details > Select All Jobs > Script Job; Is this process the best option?)
If you restore the msdb system database, all agent jobs will be held in it. There would be no need to script->restore.
5) Migrate SSIS Packages - (How to do this?)
If the SSIS packages are on the filesystem (not default) it would be trivial to create the same location on the new server and copy. By default the SSIS packages are held in the msdb system database and restoring it would get you to the same place, just like #4 and previous.
6) Migrate Database Mail Accounts/Profiles - (Create a script or recreate in SSMS?)
This is also stored in msdb. See #4, #5.
7) Recreate assemblies
These live in their respective databases. If backup and restore is used, this should not be a problem. Any assemblies outside of SQL Server would need copied to the new server.
8) Recreate Linked Servers
These also live in the master database, see #2.
Best Answer
You can significantly lower the amount of downtime by running both current and new versions in parallel. Use something like Log Shipping, Always On Availability Groups or even replication to generate a copy of your database on a new instance that is running whatever newer version you want to upgrade to. I'd go with Log Shipping as it's the simplest, technically, and is available on any edition of SQL Server. Always On AG gets you closest in sync but take a bit more work to setup. Repl is kinda in between.
It may take a while for both databases to be "almost" in sync depending on how large the database is and your infrastructure but that is not as important since your system is online the whole time. Once you get to a steady state where all existing data from the original DB has moved to the new DB and you're left with only new transactions to move, then stop transactions on the original, let all data get moved to the new DB. Actual method/command depends on what approach you take but all are well documented on MSDN.
Verify all pending transactions have been pushed to the new DB then make the necessary changes so applications point to the new DB. Finally, run validation tests against the new DB to make sure everything works as it's supposed to (even if you've tested in your pre-prod/QA environment) and re-enable applications/transactions if all tested clear.
This puts the bulk of your downtime on whatever tests you need to run and you really should not skip that part. Cutting over from Log Shipping, AlwaysOn AG or replication is a matter of minutes, assuming no server, storage or network bottlenecks.