I've done it enough to know that I couldn't do it while keeping my IC-type role as well. For me, personally, I approach systems design in a sort of breadth first search for a solution to the entire problem space, whilst deep-diving into particular areas where I am less certain. For other parts my experience lets me brush over details quite quickly.
However, that is quite different from an IC-type role, where you'll typically run into a multitude of practical engineering issues that can be frustrating and take a lot of time. Tool issues, cloud issues, bug hunting, smoking out every little detail, write unit tests, review others code, etc. That would completely throw your mental cycles in the wrong bucket.
I don't think you should do system design without having plenty of experience from IC-type roles though. You have to have understood so many different aspects; capabilities of the people at hand, the organization at large, tools, frameworks, technologies, etc, and be very, very willing to communicate the picture over and over again and take in feedback as the project progresses. It's technical leadership at one of the hardest levels.
But realise at the same time that even software development itself doesn't have anything resembling a universal theory, common processes or frameworks. It's all changing, being reinvented, and rediscovered on a continuous basis. It is equally true that many things even in medicine or construction aren't based on any solid science.