Erik's contention is that the second part after the 'and' isn't obvious at all. There's no point avoiding lock in because you're locked in anyway. You might as well just use the features and services that best suit your needs, because that way you'll make best use of your developer time and resources. I think he's right, the costs of any migration to a new cloud service are so high that it's pointless making gestures pretending you're preparing for it.
Every now and then you need to stand up a completely new system, or replace an existing system. At those times you get to pick what platform you will build it on, and Amazon wants you to pick AWS. Therefore AWS needs to be competitive.
In the vast majority of cases that decision really isn't going to be influenced by whether your existing system on AWS does or doesn't use Amazon specific tech. If you're "moving" your service from AWS to Azure those kinds of implementation details just don't matter, in most cases you're effectively going to build a replacement system and not really migrate an existing one. The costs of such a migration would in most cases dwarf any possible savings, no matter how carefully you tried to avoid lock-in.
I'm obviously generalising a fair bit, but the exceptions are likely to be less complex systems that are perfectly fine using fairly generic services.
