There's no catch. If the user does absolutely anything with absolutely any graphic, and absolutely any resize, and absolutely any HUD size the program can place the sprite on the lowest opaque pixel of the HUD by default. (And if there are no opaque pixels at all, the program can detect this too.) (It can still freeze if the sprite itself is transparent, and an index for the monster tiles is chosen since those are variable, but using a monster index can be warned about too.) Going even further, if there's not an opaque pixel in the bottom row of tiles, that can be warned about. (Because they probably want scrolling to stop for that row of tiles if they resized their hud that way.) Any catch you can think of, well, make the program catch it if possible. I believe it is possible here. I believe it is worth doing here. I'd rather have someone ask why their HUD looks different than why their game freezes.
An advanced user can turn off this default. I'm vocal on this point primarily because it freezes the game. Most other mistakes don't do this. (Except a speed of zero makes the game appear frozen, which is why I also mentioned that.)
The tool could help a lot more with this, even if it's not these specific things. Another suggestion is to give a warning about CPU usage if the HUD is low. (I'm not sure how low it should be to trigger the warning. Maybe 120 pixels.) You could also display how much CPU the wait for the HUD will use at all times. I'll try to think of more UI things the program could help with. I think you'll save yourself a decent amount of support time with changes of this sort.