The problem with that (tautological) statement is that too many people read it as: "you can't test everything, so don't bother testing anything".
I find it much more convincing if someone were to say, “test what’s easy” instead, that’s all.
Not to say there is not still a place for manually written unit tests.
And I say all this as someone who has pursued this very idea of property testing side effects for years and in the end had to admit failure. It just is too much work get right (eg uuids being generated not unique, to name just one example), and your test runs become incredibly slow, which is a killer in many REPL-driven workflows.
Expressing your state in terms of pure functions of input events, as can be done with an FRP like Reflex, means you can test all your logic purely. You can be confident that you'll only request to launch the nukes when the nukes need to be launched.
Then you have to make yourself confident that, when the system asks the nukes to launch, it sends the right signal. But that's mockable by running the system attached to device that reads the signal and reports its correctness.
And making sure the nukes take off, aim correctly, and land on their target is not my department (says Werner von Braun).
Testing definitely has value, but when testing you always have to make the assumption that you can’t test everything, and then the trick is deciding what to test versus what not to. I think people forget this and focus on having every function tested, every interface having coverage, etc.