not understanding and following requirements isn't something engineers should be doing IMO
I disagree, engineers are not robots. Good engineers may second guess and get technically involved in adjusting badly written instructions or mangled schematics, and do so all the time. And no, the "process" for querying and changing requirements is not always practical. Of course good engineers should document and report all deviations from the recspec and talk to the quality manager. Spotting that a capacitor or diode voltage is under-rated and swapping the part number, no problem. Upgrading a part if it makes no other difference seems okay too. I've been very grateful to fab or pick and place engineers who corrected a silly mistake I made instead of just sending me back a board that obviously wouldn't work. But those kind of people who take initiatives are rare to find these days,
As an engineer myself, having worked on product and having been a client of engineers working on products for me, I can tell you that engineers that think they have an inside track on what the client "really" wants are often wrong. The feeling is similar to that false confidence you get in any field when you have learned just the absolute basics, and I have felt it myself. That's why you don't just go and spend 10% of the clients budget without talking to them first. If clients are saying they don't want a feature, it's quite probable that the person you're dealing with actually knows what they want, and what they want is not what you've come up with.
A lot of projects that filter their way through HN die because the engineers are solving the problem for themselves and not talking to users. That is also the pattern you see with a lot of "what I wish I had known when I started my project" posts on here. Avoiding a conversation with the client because you're afraid they won't approve the feature you want to add is not really great engineering.