That's contrary to a number of things I've read which suggests using Application.ProcessMessages unless you can really make a case for threading.
Don't believe everything you read (including this post) but, one of the most important things to understand in a graphical application is that there is a user who will be immediately and directly affected by a poorly performing graphical interface.
Aside from the _valid_ argument that the GUI thread should not be saddled with activities that have nothing to do with taking care of the user interface, _not_ dedicating a separate thread to a time consuming task is, in the days of multiple core processors, guaranteed to take longer than otherwise. If a time consuming task is performed by a separate thread, it's very often the case that the O/S will associate a different
processor core to the task which will cause the task to be performed in less time.
Contrary to what the article you quoted states, a multi-threaded application is quite often _simpler_ than _correctly_ implementing a single thread that is attempting to carry out multiple tasks, particularly when one of those tasks is taking care of a GUI.
That said, like everything, there is a little bit of work involved in creating an additional thread and managing it but, contrary to what some believe, it's usually very simple.
In general, if some sequence of code may take 1/50 of a second or longer (on a _below average_ processor) then, dedicate a thread to it. Why 1/50 of a second ? because a lot of people will be able to detect pauses in the U.I that range between 1/30 to 1/20 of a second. Because of this, play it safe, use 1/50 (and that's presuming there is only 1 or 2 such tasks being performed by the U.I thread.)
An unresponsive interface leaves a bad impression and often tries the user's patience. These are things to be avoided.