There is no vendor lock-in with any aspect of Heroku. https://www.heroku.com/policy/promise
If you compare this to deploying to "choose a generic VPS" the lock in is substantial. If any of my apps fail, I'm comfortable I can provision an Ubuntu VPS from any provider with a one line chef command and then deploy to it with one more.
So although Heroku isn't locking you in through any bad practices on their part, by using them you're choosing to make your workflow very specific to them. To me and quite a few of my clients, while Heroku is awesome for getting started, there isn't enough benefit for the increased single provider dependency and costs.
Not hating on them at all, I use them quite regularly, but I can understand where people are coming from when they talk about Vendor lock in. Perhaps a more accurate description would be single vendor dependency.
If you're using Heroku sure you could write that cookbook but in 90% of cases it's going to end up being unmaintained because it's there as a contingency that no-one uses in their everyday workflow. What's more for it to have real value it needs to be tested regularly to make sure it actually functions as expected.
So it's definitely possible to avoid the dependency as long as you don't mind adding a big chunk of devops work. At that point you've got to ask why are you paying the premium for Heroku if you're maintaining the devops expertise and codebase to deploy to a VPS alongside?