Because the execution thread that is responsible for processing window messages (your button click) is busy performing the code you have written. Your code blocks (prevents) the thread from returning to its normal job of keeping the UI responsive to interaction. It is a common thing we have to consider when writing windows apps, not to block (keep busy) the thread that started executing the code in the button click handler. In simple terms, you have to let the thread that entered your click handler exit it again as soon as possible. In your case you have instead sent it off into a method that doesn't come back to your code for 5 seconds when what you need to do is use it to start a separate execution of the long running method, and then let it go back to processing UI updates
We do this by running the work code asynchronously or using a mechanism that will create [something like] a separate thread for it
Using async: https://learn.microsoft.com/en-us/windows/uwp/debug-test-perf/keep-the-ui-thread-responsive
Using backgroundworker: How to use a BackgroundWorker?
(I'm deliberately avoiding linking anything that encourages you to directly create and manage your own threads. The above two mechanisms are more appropriate for modern applications)
As a side info, windows essentially works by apps having a message queue (first in first out). Everything you do (move the mouse, click, press keys) gets posted into this queue and your program has a thread that works through the events and acts on them. If you keep that thread busy for seconds on end doing your code, it won't consume messages. The operating system notices that the queue is getting longer and longer, and fades the window/puts "not responding" in the title. As soon as the ui thread is free of your code it consumes the messages and your app comes alive again.