Software that I can't put data into or take data out of isn't very useful. You can mitigate the splash damage something could do and reduce the attack surface, but at some point I'm probably going to be feeding that process some files or data stream and I'm going to have it write out some files or data stream. Those data entry and exit points are still exploitable, or acting on the data stream could be harmful. Sandboxing is good to do, but ultimately isn't the solution to the problem of malicious code. Otherwise its pretty much just a space heater.

I can kind of see what you're getting at but a pure function can both accept and return data without any risk of this data leaking anywhere unintended.

Data leaking isn't the only thing you may be worried about. What about a random number generator designed as a pure function that skews a certain way reducing your cryptographic integrity? What if what looks like a pure function from the outside you're using for some range estimate on some ballistic payload is able to detect its in a live fire scenario and changes its outputs leading to inaccurate detonation? We're talking about malicious external packages/libraries and what not coming in, assuming everything is a pure function in the compiled black box of obfuscated code probably isn't a winning strategy on keeping your system secure. Of course, everyone's threat profile and the risks of failure vary greatly based on the application being deployed.

You're definitely right that decreasing the attack surface will be an important element to improving the situation, but it doesn't really solve the problem completely. Software will always need operational room to do anything useful and in so doing will still offer an opportunity for exploitation.

Increasing the trust we are able to place in the tools and libraries we leverage isn't a complete solution either, but it will have to be an element. Currently we've got nothing but blind faith and crossed fingers.