polynomial time as 'efficient'
Computer scientists draw a famous line in the sand: an algorithm is considered 'efficient' if its worst-case running time is bounded by a polynomial in the input size, that is O(n^k) for some fixed constant k. Anything that needs exponential time is, by this convention, 'inefficient' or 'intractable'. This is the dividing line that defines the complexity class P (problems solvable in polynomial time) and underlies the whole P versus NP question.
Why pick polynomials as the boundary? Three good reasons. First, robustness: the class of polynomial-time problems does not change if you switch between reasonable models of computation or programming languages, because one model can simulate another with only polynomial overhead — so 'polynomial' is a machine-independent notion, unlike any specific running time. Second, closure: polynomials are closed under addition, multiplication, and composition, so building a polynomial algorithm out of polynomial sub-steps keeps you polynomial, which makes the class pleasant to reason about. Third, the empirical observation, sometimes called the Cobham-Edmonds thesis, that problems with polynomial algorithms tend in practice to get genuinely usable algorithms, while exponential ones tend to stay stuck.
It is essential to be honest about the idealization. Polynomial does NOT automatically mean fast: an algorithm running in n^100 time is polynomial yet utterly impractical, and a 'galactic' algorithm with astronomical constants can be polynomial and useless. Conversely some exponential algorithms are fine for the input sizes that actually occur. So 'polynomial = efficient' is a robust, theoretically motivated convention and an excellent first filter, not a literal promise that every polynomial algorithm runs quickly on your data. It is a statement about scaling behavior and about a clean class boundary, deliberately coarse.
Sorting (n log n), shortest paths (about n^2 or n^3), and matching all have polynomial algorithms and are considered tractable. The travelling salesman problem has only exponential-time exact algorithms known (about 2^n), and is considered intractable — even though for a handful of cities you can solve it by hand. The line is about scaling, not any single input.
Polynomial is a robust, machine-independent line for 'efficient' — but n^100 is polynomial and still hopeless.
Polynomial-time is the standard definition of 'tractable' but is an idealization: an n^100 or huge-constant polynomial is impractical, and some exponential algorithms suffice for real inputs.