Watching this now. Some comments while watching.
I disagree with using the Python Image as an example of an issue with DockerFiles. Since that is something that as me pulling the Python image I don't need to take care of and that would be the same as any "gynastics" that Buildpack may be taking care of behind the scenes (If I understand what you were showing correctly).
You mention issues with images and vulnerabilities, but I fail to see how exactly BuildPack magically addresses this issue other than claiming that it just isn't an issue because it is "better".
IMO in the beginning it sounds like you are determined to make managing a Dockerfile as hard as possible when it really is not.
If one of your arguments is that having the choice of images (different applications have different needs even if they are the same language) is an issue your argument is fundamentally flawed. Yes there are a lot of tags for images, but they are fairly well organized for most of them and should not take long to find what you want to use.
It is great that BuildPack produces a standard Docker Image. But nothing about this changes my opinion that this is an opinionated builder that when you get to the point that you need to do something a bit funky or weird in your application or build process you will end up needing to ditch it and build a Dockerfile anyways. I don't see what benefit this has to an internally built docker image that we use in our applications so the Dockerfiles in the dev's repos are 10 lines max.
Using a "From" image for DockerFile is just as reusable as Buildpack, so that is not an advantage. Again near the end you claim BuildPack is "safe" but why and how?
If you are using Docker and your mitigation of something like heart bleed is "years" (for your images at least) your not using Docker properly and is likely a flaw in your CI pipeline and not something that this tool will magically fix since the issue is somewhere else in your pipeline (including people in that pipeline).