Reaching for enable_sort = off because a query has a slow sort in it is usually aiming at the wrong target. When a sort is slow, it is generally because it spilled to disk, which is a work_mem problem. When a sort genuinely should not be there at all, the fix is an index. enable_sort changes neither of those, and setting it off is rarely the thing you actually want.
Default on, context user, and it reaches unusually far. An explicit sort does not only serve ORDER BY. It sits under GROUP BY when the planner chooses to group by sorting, under DISTINCT, under UNION and the other set operations, and under every merge join, which requires both of its inputs sorted. Turn enable_sort off and you are not nudging a single plan decision; you are changing how the planner approaches all of those at once. That breadth alone should keep it out of postgresql.conf.
When you do have a slow sort, EXPLAIN (ANALYZE) tells you which kind on the Sort Method line, and the kind is most of the diagnosis. quicksort with a Memory: figure is an in-memory sort and is fine. top-N heapsort is the bounded sort used for ORDER BY ... LIMIT n: it keeps only the n rows it needs and is cheaper still. external merge with a Disk: figure is the one to care about, because the sort outgrew work_mem and spilled to temporary files, which is far slower since it trades fast memory access for slow disk I/O. When you see external merge and the spill is not enormous, the fix is to raise work_mem for that session so the sort fits in memory. Disabling the sort does nothing here; the sort was the right plan and simply needed more room.
The other case is real too: sometimes the sort should not be there, because a btree index already holds the rows in the order you asked for and can return them without sorting. Where this matters most is, again, ORDER BY ... LIMIT n. An explicit sort has to read and order the entire table to find the first n rows, while a matching index walks straight to them and stops. That is the plan enable_sort = off exists to surface: flip it in the session, re-run EXPLAIN, and see whether the planner switches to an index-ordered plan and what it estimates that costs. If it does and the estimate is lower, your fix is that index, not this switch.
But do not assume the no-sort plan always wins, because it does not. The documentation is explicit that when a query reads a large fraction of a table, an explicit sort is usually faster than pulling the rows through an index, since the sort reads the table sequentially while an index scan chases rows in random physical order. Indexes win when you fetch few rows; sorts win when you fetch many. The knob lets you find out which regime a query is in. It does not tell you the answer.
Two things enable_sort does not cover, both worth knowing. It governs the full Sort node only; incremental sort, which sorts within groups sharing an already-sorted prefix, is a separate node with its own enable_incremental_sort, so turning off full sorts leaves it in play. And for GROUP BY and DISTINCT, the planner’s real alternative to sorting is hashing, which it already weighs without any help; enable_sort = off mostly just tips that decision toward the hash.
Leave it on. Like the rest of the family it is an instrument rather than a setting: you point it at one query to ask whether a cheaper plan without a sort is available. The sort tuning that actually moves your database lives elsewhere, in work_mem and in the indexes that let the right queries skip sorting altogether.