I think you make some really strong points here and I completely agree that learning to deal with inevitable failure and working through it matters. I'd offer one small addition though:

>XYZ isn't finished yet - no you're not done.... that's TOTALLY ok. Every homework assignment starts off with a grade of F - you work on it to get to a C, B, or A. A startup's work is never done, there really is no success state, and that's OK too. You're helping to make the product better, you're delivering features to customers. Your making the task pipeline faster with your automation tools. Things suck - but you're making life easier for everyone tomorrow.

It's worth noting at the same time however that "effort" alone isn't enough. Some ideas really just don't work, either because it turns out it's not something the market actually values, is simply beyond any amount of effort with present technology, oneself/one's organization simply doesn't possess the capability to execute on it (often for perfectly good structural reasons), etc etc. If the homework assignment is "wacky acme item a grand total of 12 people in the world want that will cost hundreds of millions", "factor this 256-bit key" or some equivalent of "develop a working Unified Field Theory" it's unlikely most of us are getting an "A"! Obviously IRL it's not typically so clear, but non-domain expert stakeholders (be it management, users or clients) don't always have any great way to understand themselves that their "simple" requests may be a grabbag of "one of the interns can knock this off in an afternoon", "if the team focuses this can be done in a few months", "if this was Apple/Google/Microsoft devoting massive resources to a cutting edge unit they might pull it off in the next few years" and "ask our a strongly superhuman virtual intelligence descendants in another 50-100 years". It's a job for professionals to help inform what's possibly feasible and what isn't too, and an organization which just says yes isn't healthy. But of course not everyone has the luxury of just packing their bags even if an organization's sales side constantly writes checks development can't cash.

It's also a classic startup trap to spend too many resources on tooling/infra that will make life easier for a tomorrow which will never come because they go under first. Getting the balance right between ugly hacks needed to hit targets cheaply and scaling if the startup works is often super hard. In all this implementation is more important than ideas, and a lot of solid hard work on something junk is still going to fail.

So I think it's also important to emphasize that sometimes no amount of working on it will get from an F to a C, B, or A. There is a time to cut losses, and some initial effort should be expended on getting a feel for basic viability before too much time is sunk so it's possible to pivot away. All while not losing hope about trying again because you can definitely always get that C, B or A in a future effort. No perfect map for that either though. Is grand success just over that next hill, or just a slide down into quicksand? And sometimes a very valuable effort comes out of some side project or individual feature that customers love in an overall product which bombs.