Is it normal for one module to spread all over the die after implementation?

That smear is usally the tool doing its job, not a bug. DSP-heavy math tends to spread out because the placer is hunting for routing room, and if it closes with positive slack, that thin layout might actually be what's keeping it closed. Don't assume tight equals good. That said, your instinct about the next revision is right. I'd draw a pblock now, on a copy of the design, while you still have margin to burn. Two rules that saved me on a similar data path: leave plenty of empty room inside the box, don't pack it anywhere near full, and keep the rectangle closer to square than a long skinny strip, because skinny shapes choke the routing at the edges and you'll lose slack fast. Then run the design both ways and compare the timing reports. If the floored version gets worse inside the box, loosen the rectangle or just drop the constraint. Also worth poking at why it smears in the first place. Sometimes it's one wide register or a big mux fanning out, and adding a pipeline stage fixes the spread better than any box you can draw.

On the slides, screenshots will always look mushy because you're grabbing raster pixels at whatever zoom you had. Export to a vector format like PDF instead and the lines stay crisp on any projector, no cropping needed. That one switch ended my screenshot misery years ago. One last thing: a hair of positive slack is not real margin. Corners and process variation will eat it, and then your new logic lands on top of a design that was allready marginal. I'd want a comfortable buffer before stacking more onto it.

I ran into this issue once where the physical size wasn't the main culprit, but the placement effort the tool was putting in. I learned that lesson after a massive design crash when I finally switched my synthesis tool setup to a more constrained approach instead of letting it run wild. It made the initial place take twice as long, but it kept the placement effort lower.

Maybe instead of just looking at the area of that smear, check the placement effort metric. If it's close to maximum, adding a pblock might just give the placer a cage, but it doesn't fix the inherent crowding. If you want a buffer for future logic, try to keep that effort metric well below 80% before boxing anything in.

I've actually had more luck focusing on the clock region. Instead of just boxing the math, you can tell Vivado exactly where the main clock is supposed to sit. It forces the placer to cluster things around that clock source, which usually cleans up that weird sprawl you're seeing. It's often easier to manage the spread that way than trying to figure out the right pblock boundary manually. What about making sure your inputs aren't driving too many registers at once?

You might be looking at logic spread when the issue is actually pin placement. The tool often spreads blocks out because of how it's handling I/O routing between them. I ran into this exact problem once and realized a single signal had a fanout count of 15, but it was driving registers sitting in four completley seprate I/O banks. That forces the placement to scatter wildly just to keep those traces short. Try forcing the interface blocks into a specific bank group; you'll stop the smearing before the layout even starts.