Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)

I think this is true for essential complexity. And indeed it's one of the best reasons to release early and often, because usage helps clarify which parts of the requirements are truly required.

But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do.

Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.

You absolutely can remove unnecessary complexity. If your app makes an http request for every result row in a search, you'll simplify by getting them all in one shot.

Learn what's happening a level or two lower, look carefully, and you'll find VAST unnecessary complexity in most modern software.

If - to take a convenient example - I use a library sorting function instead of writing my own sorting code, it's true that I haven't removed the complexity of the work my program is doing: It sorts. But I have arguably reduced the complexity of my code.

Similarly, if I factor out some well-named function instead of repeating the same sequence actions in multiple places - the work to be done is just as complex, and I haven't even removed the complexity from my code, but - I have traded the complexity of N different pieces of code for 1 such piece plus N function calls. Granted, that tradeoff isn't always the right thing to do, but one could still claim that, often, that _does_ reduce the complexity of the code.