x64dbg's "Threads" page only refreshes once every two seconds, not nearly fast enough to see much going on in threads that are mostly blocked waiting (such as an application's message loop thread).
You can verify that the thread is getting time-sliced by watching the "User Time" column. Move your window around for several seconds, and you should cause enough application code to run to see the "User Time" increment.
Edit addressing @Duke Nukem's comment:
Active debuggers on Windows rely on an event system, so most of them just sit around and don't do anything until an exception, breakpoint, or user interaction happens. These debuggers (WinDbg, VS, etc) won't show any thread state or anything like that while the target is running (you only get that information when the target is broken into).
This is where the confusion is coming in for people not familiar with x64dbg. The x64dbg Threads tab isn't tied into the debugging events system, it is just a monitoring tool that periodically scans all the threads in the target (even while it is running) and grabs timing stats and also queries the thread's context in order to display the current instruction pointer.