As someone who is an actual systems engineer, and competent in fields including both programming and physical, the point isn't difficulty but iteration cost. It costs next to nothing to push a modification to software. Worst case, it fails, and as long as you are careful with testing things will probably be fine.

Anything in the real world both incurs significant logistical cost as well as many points of unpredictable failure. I've seen thermocouples rated to 1100C catch fire when they hit 600C. Designing a new part for a new idea for a mechanical subsystem can take weeks to make, cost $1000+ easily, and might not work due to very easy to make errors.

So maybe the way to say it is that the abstraction barriers put around non-software parts of a system make them appear less complex, but what we're really saying is that the complexity inside of the box that we're dealing with is smaller.

It's not easy. It's damned difficult and we both know it. But effort "funnels down" into conceptually simple results even more often in non-software engineering. It has to, or physical engineers would never get anything done. Choices like fuel/oxidizer composition, stage design, and nozzle type can be (relatively) easily specified no matter how much trouble went into deciding between alternatives. Pages of physics calculations and days of simulation bake down into a few numerical parameters in the final design.

I think what's happening here is that you know and respect the amount of effort that goes into rocketry and your mind is inferring a level of complexity that matches. Effort(times)skill is one correct way to judge the magnitude of a project, but I argue that complexity of the product bears little relation to either effort(times)skill or the project's success.

Rocketry was a bad example because the scale of a typical rocketry project is so large that dividing by cost (or effort(times)skill) becomes critical to making the comparison.

As someone who learned CS before diving into MechEng, I must conclude that this is nothing but truth. The problem is, once physics gets into the equation, everything goes so complex that you can't live without approximations. But apparently in MechEng you can't live with spherical cows in vacuum, either, so you need models that could represent what you really care about (strength, rigidity, dynamic stability, structural integrity, wear resistance... just to name a few) and there you go -- complex, even when you only have a few "components".

TL;DR : Sure. MechEng seems easy.