Structurally, Claude will suggest you take the simple solution for a problem you're experiencing. Historically speaking, that's the smart solution. In times of costly development hours, there's a need for constant triage.

Is this investment worth the upside? Spending time on this will eat time on something maybe more important.

But in a time of abundance, which we now live in when it comes to development resources, this changes entirely.
Here's my LLM telling me to combine two partial solutions because the complete one is "te veel werk voor nu." It's technically correct advice—if you're paying engineers$150/hour and shipping features matters more than architecture.

But I'm not. I'm paying the LLM the same whether it writes 40 lines or 400. The "2-3 dagen werk" estimate was calculated in a world where that time cost money and opportunity. In this world, it costs an afternoon of iteration.
The LLM doesn't know this. It pattern-matched on 30 years of software projects where C was always too expensive. It looks at all the historical data available on software development and tells you the thorough solution you're looking for is not worth the development time. It bases that judgment on its 30-year knowledge of development projects it's trained on.

It highly underestimates its own capabilities.

So it confidently tells me to take the compromise, hash-skip for 80%, morphdom for the polish, accept the edge cases. Meanwhile, option C sits there: best UX, works offline, no client-side diffing complexity, no libraries, no bugs from "kleine changes."
The only thing wrong with C is that it used to be expensive.
Thankfully we understand. So always pick C. Go native. Build the thing that would've been "too thorough" in 2015. Those frameworks that speed things up? They were invented to compress development time when development time was the constraint.
It isn't anymore.

Pick C.