There is a tight coupling between the user experience (UX) and the user interface (UI). They are often synonymous, I think they are nearly interchangeable in many aspects.
I think it is safe to say when you block the UI thread with some long running process you are *blocking* the UX from being as good as it could be. Maybe when multiple processors were not really prevalent I could accept it. Now I can not. I know better and now so do you (or at least you have my word of caution.) Short of citing examples and writing tutorials to show you I know better you know better from reading this PSA. You have an entry point to discovery. Go do it! NOW! The next time I see an app run and go get data and block the UX and create an unresponsive app I will bring out the gauntlet of shame and slap you with it! Since no one really reads my rants the world is pretty safe ... For the moment. Soon to follow is my PSA on creating threads all 'willy nilly'. There is a time and place for it... A good rule of thumb, never spin up another thread. And then only do so when a queued/scheduled task will not suffice. Do everything on one thread AS MUCH AS POSSIBLE, but be smart and don't tank your UX (I know I know, its not easy, this is tough love time.)
There is one exception to my tolerance, Dwarf Fortress, although since having gone to OpenGL (did I date my playing time?) I rarely encounter anything less than 45-60FPS except when my fortress is collapsing and/or filling with lava and water... (physics/fluid dynamics baby! the simulation demands it! the simulation must have its synchronous way with you! I have a very unhealthy love of Dwarf Fortress... I know this...)