In a networked app where your latency is too high for these figures, or if you need to do some large number crunching etc, you should instead focus on giving the user feedback that progress is occurring. A progress bar, a spinning ball, etc are far better than nothing. Just as long as you acknowledge that the user has requested an action, and give the user confidence the action is proceeding.
That, I don't disagree with at all. There's been more than one time I've clicked on something, and then waited for the computer to do something that lets me know it's received my command and acted on it. It can be damn frustrating.
My intuition says that's steep. Noticeable change 1 frame later might be doable with a web app, if the app is structured well and focuses on fast response times. However, I don't think actionable information two frames later, or a full screen of content four frames later is feasible for a network-based application, especially given the fact that just crossing local layer 3 network segments can add 10s of ms to your latency, depending on the router's load.
Really, these numbers strike me as only achievable by an application where all data and processing is done locally on the computer that controls the display. Even then, these target numbers still feel steep.