I'm neither Colin nor a cryptographer, but I think elliptic curve cryptography (1) involves more complicated ideas and code (which might therefore be easier to get wrong), and (2) is subject to more patent claims, than its rivals, without any obvious big benefit to outweigh those facts. [EDIT: oh, and because of 1 and 2 ECC is used less, and therefore your implementation mightn't have had its bugs and design flaws so thoroughly shaken out.]
Certicom has ~130 ECC-related patents. You probably don't want to have to crawl through them all making sure that your code, or someone else's code that you're using, doesn't infringe (and won't be found to infringe by a not-necessarily-infallible jury if you get sued anyway).
[EDIT again: actually, ECC does have a claimed big benefit, namely not needing such long keys. But one might reasonably be worried by the possibility that an algorithmic breakthrough some day might suddenly make longer keys necessary...]
ECC is extremely well studied and implemented almost by default in embedded settings. There are providers of it other than Certicom.
The reality is, you need to consult a cryptographer before you implement any public key system. RSA and vanilla DSA are also spectacularly easy to screw up.
In an embedded environment I would probably use ECC. I believe that I mentioned this in my talk; certainly I mentioned that my advice was for the context of software on general-purpose CPUs.
ECC vs. RSA is a place where you certainly know better than me; I have that list of things Kaliski said not to do wrong with ECC and very little else. I also think we probably don't disagree very much about ECC.
Where I know we do disagree: public key crypto is a threshold over which I would not be OK implementing a custom cryptosystem. If I need public key, it's GPG or nothing. I am terrified of public key crypto.
I didn't intend for my audience to be implementing everything themeselves. Knowing that OAEP is better than PKCS padding is useful even if you don't write a single line of code, because it helps you select the right library to use.
Certicom has ~130 ECC-related patents. You probably don't want to have to crawl through them all making sure that your code, or someone else's code that you're using, doesn't infringe (and won't be found to infringe by a not-necessarily-infallible jury if you get sued anyway).
[EDIT again: actually, ECC does have a claimed big benefit, namely not needing such long keys. But one might reasonably be worried by the possibility that an algorithmic breakthrough some day might suddenly make longer keys necessary...]