You're basically saying that preservation is easy if the original developers took preservation into account. The article is making the point that developers and ecosystems increasingly don't consider preservation ahead of time.
> One, you can preserve the binary and run it with emulation. For webapps, this means preserving a deployable image. Your faddish/brittle dependencies are 100% irrelevant, because your image includes them already, right?
And what if the software's build artifacts aren't binaries or deployable images? Many projects (most, I suspect) don't output either.
> Or two, you can preserve the source code. Which for any project is going to involve a mess of complicated tooling that dates to when the project used to be compiled.
Well sure, but some projects have more mess than others. That's kind of the point of the OP.
> But if you're intending to preserve something for the long term, you should preserve the dependencies too -- e.g. node modules or whatever.
And if you made the decision to preserve the software long after it was initially developed, what then? Most people explicitly don't put their node_modules folder in version control.
> I don't really see what's all that different.
What's arguably different is that many of the currently popular ecosystems don't really value long-term maintainability, stability, or preservation to the same extent as the popular ecosystems of yesteryear did. Projects in these ecosystems can end up broken on a much shorter timeline than in other ecosystems. Project breakage also has a way of causing cascading problems.
I'm not sure why you're confused, you seem to have a good grasp on the solutions to these problems. Perhaps you're unaware that it's common practice not to implement those solutions ahead of time, and that is exactly what the OP is complaining about?