"Doesn't this mean, full stop, that good developers should not even consider working for such start-ups?"

No, I don't think so. Just because you're not doing novel computer science or engineering doesn't mean you aren't doing interesting work, or that your work isn't valued. I think the point is that from an investor's perspective you aren't going to learn much from poking around the code and saying "why'd you use this library rather than that library?"

I can offer my own personal perspective on the value of developer talent as a quasi-technical (I'd say on a good day I'm maybe a 0.9x engineer, most days more like 0.5x :) co-founder of a SaaS company that definitely isn't doing any ground-breaking computer science. To me, the value of a top-flight engineer isn't that they are going to overcome a problem so hard that no "normal human" (like myself) could ever solve it. It's that they are able to look at the fairly vanilla problems we are facing (usability, scalability, etc.), see better solutions than I see, implement them faster and more robustly, and avoid pitfalls that are obvious to them but aren't obvious to me (because I lack the experience to spot them). Maybe we could hire someone cheaper to do the same work, but it would be half as good, take twice as long, and be four times harder to build on in the future.

So to me, having top-notch developers is a business issue, not a computer science issue. Let's face it, even at companies that are doing novel computer science, most of the work that most engineers do is going to be pretty mundane from a CS perspective: Google may be doing amazing work at the boundaries of technology, but someone still needs to maintain the mouseover behaviors in Gmail...

Which is not to say that development work not at the boundaries of technology is inherently uninteresting! I think most people who code (even sub-par coders like myself) get off on a lot of things other people would consider pretty boring, like (in my case with some work I'm doing right now) figuring out a reasonable stop-gap way to manage state when creating a new object that requires putting some hooks into multiple third-party APIs. This is not a novel problem, but there are a lot of ways to solve it, and it made me happy to implement one that is simple and fails in a reasonable way even if it isn't maximally flexible/robust.

Of course, not all founders/managers/executives "get it". And those that don't may opt to just hire the cheapest while paying lip service to hiring the best. But I think (shamelessly tooting my own horn) that people with some experience in the weeds, or with personal exposure to the range of engineering talent out there in the world, recognize hiring sub-par talent is a false economy.

And of course there are all sorts of other factors that go into choosing where to work: can I stomach working with these people every day, does the job fit with my personal life, is the executive team technically illiterate and prone to giving us impossible tasks, etc.

TL;DR: Engineers can be highly valued even when their work isn't "novel" to the point of requiring technical DD at the time of an early stage investment (there are those of us out there who recognize the value of craft), technical work doesn't have to be groundbreaking to be interesting, and making the choice to hire top-notch talent is usually a business decision, not a technical one.