The -x option is useful to keep the clock monotonic, but the clock is inaccurate for very long time when the offset is large. That's not acceptable for default configuration. Also, it disables the kernel discipline, which usually makes the quality of the timekeeping worse.

Actually the request is as per Red Hat case 01492484.

Summary Text (TL;DR)
Any method of adjusting time that relies on time stepping backwards is the worst method. Pick some other method. As long as it does not involve time stepping backwards (which is absolutely ridiculous).

Full Text: 

Request feature enhancement by Red Hat to ensure 'slew mode' of NTP clients is the default and *always* the default (e.g. during leap seconds). I know it is configurable, but what proportion of customers would ever, ever want 'step' mode during leap seconds?

Whoever decided that the correct approach to handling leap seconds should involve time 'stepping backwards' must live in a universe where transactional systems don't exist.

I'd argue that the majority of your customers don't care. However, those that do care would prefer 'slew always'.  The small percentage of your customers who want accurate time with the real world still would not use the Linux implementation of jumping time backwards.

For example: the Australian Stock Exchange:http://www.sfe.com.au/content/notices/2015/0291.15.03.pdf

ASX’s Trading platforms will Manage all transactions in the sequence they are received. Progress time forward as the time synchronisation will occur by slewing the time, not by moving the time backwards, or repeating the time.

The Linux implementation of leap seconds is absolutely ridiculous. Windows actually caused less problems simply because it ignores leap seconds.

I think there are basically three criteria when handling an inserted leap second:

A) for how long is the time inaccurate? (it can't be shorter than 1 second due to missing representation of the 23:59:60 UTC second on the Unix timescale)
B) is the time monotonic?
C) do clocks of computers in the network stay close to each other?

If we evaluate them for the -x option, we get:

          |  A          |   B       |   C
ntpd      |  1 second   |   no      |   yes
ntpd -x   |  >1 day     |   yes     |   no

By enabling the -x option we trade A+C for B.

In both B and C are important, it's necessary to use a leap smearing NTP server that will hide the leap second from the client ntpd and in that case it doesn't matter if it uses -x or not.

          |  A          |   B       |   C
ntpd      |  1 day      |   yes     |   yes
ntpd -x   |  1 day      |   yes     |   yes

For more information see
http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/

Even if we ignore the problems with extremely long correction of the initial offset and worse timekeeping performance due to disabled kernel discipline, the leap second behavior of -x is not always preferred and some users would need to disable it if it was enabled by default. The current default behavior is known and adding -x needs to be an informed decision. In cases where the time must be monotonic and also stay close to other hosts in the network, enabling -x wouldn't help anyway.

Few points:

1. Is there not an option that will satisfy A, B and C?

2. If I were to rank A, B and C in terms of priority; most of your customers don't care. But those that do care, would rank B highest priority.

3. Again, any method of adjusting time that relies on time stepping backwards is absolutely ridiculous.