Timing budget refers to what portion of the clock period remains after you account for all the system delays. What are these delays? Things like setup and hold times, propagation delays, routing delays, combinational logic delays, clock skew, etc.
For example, let us say that you want to run at 200MHZ clock, or 5nS period. If you add up all the maximum delays and the total delay in the signal path is less than 5nS, you will meet your timing budget. If the total delays are greater than 5nS, then you will fail your timing budget and you must increase your clock period or risk clocking failures in the system.
FPGA design tools know the worst case numbers for these delays and use this info when placing and routing the design as long as you inform the tools of your clock period. The FPGA tools will try to optimize the design so that all paths make the timing budget. Any paths that fail the timing budget will be in the error report.
Robust designs always try to have some timing budget left over. The reason is that clock jitter is really hard to estimate and a system with zero timing budget can fail at unpredictable times due to clock jitter.
While FPGA design tools can move the logic around to minimize the routing delays. It can also duplicate logic functions that drive loads that are on opposite sides of the chip. The FPGA design tools cannot do much for large combinatoral delays between flops. This is where pipelining comes in and helps you make your timing budget.