Technical debt is the amount of sub optimal code in a particular code base. Examples include breaking Single Responsibility, overly complex methods, or plain old “quick fixes." Code laden with technical debt is hard to read and even more difficult to maintain. Many times this code is under test, creating FUD (Fear, Uncertainty and Doubt) in the developers responsible for maintaining it.
There are many reasons debt creeps into a code base, from junior developers not knowing any better to tight schedules that hinder writing code the “correct” way. After all, releasing is a feature and code not in production does not provide any business value.
Technical Debt does not always need to be paid back (although one can argue that it should be). The determining factor is the business value of the proposition. If the code is working wonderfully, does not need additional features or bug fixes, a valid option is to leave it alone. However, this is rarely the case. Software seldom stays stagnant, and maintenance is a large part of the corporate developer’s life.
When saddled with legacy code that has a high cyclomatic complexity or other untenable cruft, refactoring becomes an extremely important tool in the developer's arsenal. Paying back technical debt can be painful, but the return on investment (especially in volatile code bases) is extremely high. It all comes down to saving developer's time and effort (and thus money). Three examples of why refactoring should be used are related to code maintainability, code readability and code extensibility.