2) In suggestion six I specifically warned about leaving the machine powered on. Don't get me wrong, it is a viable concern, but one a user/enterprise could easily correct with proper usage policies in place. Also, what stops the end-user/enterprise from encrypting the whole disk and partitioning another part of the disk to store sensitive information that is also encrypted? Then the user/employee/whoever could simply decrypt/mount the partition when they need access to the data and encrypt/unmount the partition then they are finished. If you really wanted to argue just for the sake of argument, then nothing on this planet is truly secure and you could go down an infinite rabbit hole that is a never ending echo of what if's, theoretical possibilities, etc. These are steps increase physical security, not make you completely immune to all forms of attack. With anything, user habit and policy is the most important factor when paired with reasonably strong encryption.
3) I understand that a lot of offices across the globe use outdated hardware. However, how often do you expect someone to be able to perform a Cold Boot Attack in the required time frame? It isn't overly complex, and can certainly be done with commonly found (cheap or free) items/software, but it isn't something to really get worked up over. Offices with confidential data should already be utilizing strong physical security policies (security, CCTV, locked computer chests, etc) and was simply outside the scope of these suggestions and not directly related to the discussion, this is a huge reason why I didn't go into details regarding counter-measures, as most are unrelated. Also, I don't see a home user having to worry about this type of attack. Sure, it might be possible they would encounter a CBA, but it is also possible they could win the lottery twice - doesn't mean it will actually happen in their lifetime (and home users are more likely to be using newer hardware also).
4) Why would it matter if an attacker installed a boot loader on an encrypted drive? If you used this suggestion then you would not be booting from it, it would give you one heck of an obvious clue that someone was tampering with your system, would not give them access to the encrypted contents of the drive, etc. If anything, all it would do is give them away since you wouldn't even be booting from their malicious new boot loader to begin with. Also, not losing removable media is not all that hard. If you managed to lose it, then that is simply the price of security and why recent/secure backups are very important.
5) I don't specifically target enterprise or home users with my advice. You would be surprised how many home users do use smart cards and fingerprint scanners. Both are not very difficult to set up, are fairly inexpensive these days and offer increased security. For example, the FS88 fingerprint scanner can be bought for under $100 USD in a lot of locations. There are also a lot of decent smart card readers out there for under $100 USD also. To answer your other question, it isn't too difficult to set up the fingerprint scanners that come with laptops. Some might require you to use documented API to create the required modules/software to utilize the devices, but projects like fprint can help make such things possible for end-users with no programming experience. Heck, even in cases where you need to use the documented API, they almost always include an example that only needs slight modifications to meet most home user requirements.
6) That is what I was driving at. I meant to say that you shouldn't be using the guest account and instead use a standard user account that is heavily restricted to only the software/access they need to perform a specific role/task. My fault, though. I didn't really convey that point correctly. Also, I have seen many people/organizations store off-site logs. It can be really nice to have an off-site logserv. It makes centralizing live log analysis easier in addition to hindering an attackers ability to hide nefarious actions by simply removing the log entries. Running as a standard user with SELinux, etc. was (I thought) implied by: "I meant to say that you shouldn't be using the guest account and instead use a standard user account that is heavily restricted to only the software/access they need to perform a specific role/task", so I do agree with that overall sentiment.
Again, please take all of my suggestions as a whole and not individually. When they are all added together and properly implemented, do you really argue the overall physical security of your machine would not be improved?