I've seen confused users who missed/ignored the tiny OK window, and through the app froze, because the large parent window stopped reacting to clicks.
You can do the same on a desktop app too, but it is less commonly done. To further avoid confusion, try make sure the pop-up modal appears over the parent window that it is blocking input for (this may mean coding your own window instead of the platform default alert/confirmation box, if the call to open one doesn't allow positioning information to be specified). I've seen alerts/confirmations pop-up on a different screen to the one that the parent window is on which makes missing it much easier (especially if the other screen is away from the main one, perhaps it is being projected at a wall for a demo). To further help: if the user clicks the disabled parent, move the pop-up to where they clicked – usually the title-bar or other chrome on the pop-up flashes in this case, but that isn't helpful if it is on screen 2 and the user is staring intently at screen 1.
Just don't.
> Just don't.
Except where it actually makes sense to. Or you are trying to improve the UX of something that already works that way and you don't have time/budget/permission to reengineer more thoroughly.
Where it makes sense to the “technological hackery” isn't pointless: where the UX pain can't be easily removed the visual hackery at least reduces it to a minimum. Similarly for when you are stuck with the overall design (at least for now) and are trying to minimise the suck for the user.
I'll not disagree with going fancy and adding blur filters & whatnot is showboating, I'm firmly in the function over fancy tricks camp too, but many people want things to look pretty as well as be functional¹. And once you are already doing the functional, the few small tweaks to make it prettier are hardly hard work so don't waste enough time to deserve the level of incredulity you are expressing, so while I might not bother I'd not judge others for doing so as long as the fancy doesn't get in the way of the function.
--
[1] heck, some will judge your work on the visuals before even thinking about the functional matters
[2] or take more time than refactoring the UI to remove the need for the modal, if that is possible/practical
There was never a more obnoxious showboaty in-your-face modal dialog than the OPEN LOOK popup notice (as implemented by XView and other toolkits that I won't mention out of shame), with its pointy triangular tail, that would actually violently "warp" your mouse pointer location back and forth between the originating button and the "OK" button:
https://www.oreilly.com/library/view/volume-7a-xview/9780937...
https://www.oreilly.com/api/v2/epubs/9780937175873/files/bg4...
https://guidebookgallery.org/articles/facetofacewithopenlook
https://guidebookgallery.org/articles/facetofacewithopenlook...
https://guidebookgallery.org/articles/facetofacewithopenlook...
Open Look modal dialogs were so disruptive they must have been inspired by the Chest Burster scene in Alien:
https://www.youtube.com/watch?v=AdBu6VAESeI
The one thing OPEN LOOK did get right were the pushpins. It annoys me to see so many "modern" half-assed semi-skeuomorphic pushpins that instead of actually pushing in just remain in the "not pushed in" state, but highlight a framing box instead. It's in the name, people. It's supposed to pin the window on the screen, and how can it do that it it's just highlighted instead of actually pushing into the hole? Pushpins REALLY should safely and satisfyingly push in, not just sit there sharply pointing out at you menacingly like that. It's not rocket science so I don't understand why so many pushpins don't push in. Was there a user interface software patent on pushpins that push in?