I wouldnt call it utter nonsense.
This was explained to me by an engineer at sandisc. Also verified through lexar pro. Several years ago, there was a ton of BS information going around the net about factors that contribute to card failure. I met some people from Sandisc and asked them the questions and their expertise regarding the problem\and the misinformation going around the net.
This was explained to me word for word and why they suggest doing it this way.
That's because if your camera blows up a card by writing to it incorrectly or incompletely you'll know who to blame (the camera maker.) It has exactly nothing to do with workflow and you're sacrificing a non-trivial number of cycles by doing it this way. If you use crap hardware on the PC side then the smart thing to do is NEVER write to the card at all, because if the timing is wrong you will damage the format (and in extreme cases you might damage the physical card!)
That's correct although it's not "slow or lazy" per-se, it's just FAIL. You write to a cell and when you read it back what you put there isn't there any more.
Flash has gotten better at not wearing out as quickly over the years, mostly through tuning the write amplification parameters in the firmware on the card itself. That is, they use less current and thus consume less of the available life "per-cycle." The manufacturers also implement wear-leveling and some have a limited amount of spare space built into the card (and not reported) which the controller can use to remap errors it detects. This is somewhat compensated by the higher density of card, which makes the problem worse (each cell on the chip is smaller.)
True and false; keep reading.
If there's written data that later disappears it's either because the cell in which the data was deposited failed, there was physical (including ESD) damage inflicted on the card or the card's internal read-after-write verification was insufficient to guarantee that the data was actually durably written into the flash.
All other "read failures" are due to a DEVICE scrambling the card, or a USER interrupting a write before it was complete.
An SD card is a block-addressable device; nothing in the card architecture specifies the filesystem and its structure, nor how safe it is in the event of interrupted writes and similar events. There is nothing (other than device manufacturer choice and interoperability) preventing the use, for example, of a journaled filesystem on an SD card which is extremely resistant to user-caused (or power-interruption caused) damage. FAT (both 16 and 32) along with exFAT are used for compatibility (mostly backward compatibility!) reasons rather than robust operation. FAT is especially annoying too when it comes to video files since FAT32 is subject to a 4GB file size limit.
There is nothing, incidentally, prohibiting a camera from doing a check on the FAT format when the card is inserted and complaining at that time if there's a problem. None of them do to my knowledge; they just check that the directory structure they want is there and if it's not present they claim the card is not initialized. It's not very nice of them to do that, but it is what it is.
The vast majority of "PC-caused card problems" are due to someone yanking the card out of the reader with half-completed I/O on it. That will pretty-reliably screw up the format on the card and you might not notice right away depending on where the screw up is. Obviously if you NEVER write to the card from a given device (e.g. your PC) then that can't happen on that device. Your camera is somewhat-protected from this in that there's a switch on the door (ever notice how the card-access light will flash when you open it?) that forces a buffer and directory flush and shuts down the camera when opened in an attempt to prevent that from happening.
So what your "engineer friend" was doing is feeding the pablum that those who don't understand what's going on can use as a shield, rather than telling you that if you yank a card that has files open for write out without dismounting it first you're asking for trouble, and that this (user stupidity) is where most of the problem comes from.
There are exceptions though, for specific devices that aren't quite as compatible as they claim.
If you want to see a prime example of this in action go grab a Samsung SGS II or virtually any of the older series of HTC phones allegedly "compatible" with 32GB microSDHC cards. Format them in the phone and then write data to them over the USB connection on the phone, which allegedly should be completely "safe", since the card never leaves the device. You'll get a surprise (and not a pleasant one either); the firmware and hardware in those devices is notorious for having trouble with the 32GB SDHC cards, mis-selecting the location to write into and scribbling all over your data. The same phone will happily write and read 16GB cards without a hint of corruption -- ever.
My background on this stuff includes working in the days when you had to do this timing yourself on embedded systems (I wrote the code to handle this sort of thing on dedicated controllers for satellite earth station gear); I know how the technology works at an actual operating level. The card manufacturers are simply trying to reduce the number of places that a device can blow it and they're presuming (which is not a terrible presumption) that your $3,000 camera has a better quality of engineering in it on the CF or SD interface than does your $10 card-reader on your PC, not to mention that they know there's a door between you and the card on the camera and the camera has a switch on it so it knows when you open it and can (try to) flush before you extract the card. In addition they've seen enough cards that are allegedly "defective" with screaming customers on the other end of the phone that had absolutely nothing wrong with them beyond the customer yanking it out of the PC it was in while there were files open for write, which destroyed the FAT block freespace chain -- and were then stuffed into a device that didn't check the chain integrity (your camera, for example) on insertion. Some time later (and usually not too far later) they take a picture and three of their previous photos get partially overwritten, badly corrupting the data.
But the problem wasn't the card or where it was written, it was the user.
You can format every time you use if you wish. I understand the technology I'm using and know how to avoid screwing myself, and choose to simply erase the files once I copy them over instead.