Won't this break backward compatibility? What happened to "don't break userspace"?
Introducing an option to omit functionality does not break backward compatibility; just build with that option enabled (which remains the default) and existing userspace will continue to work.
These types of embedded options are intended for purpose-built systems, where the builders of the system know all the userspace code that will go into it, and can safely omit system calls or other functionality because nothing will invoke that functionality.
Devices in /dev are user-facing interfaces, yet you can compile them out or make them modular. Virtual filesystems like sysfs and proc are user-facing interfaces, yet you can compile part or all of them out. Filesystem names passed to mount are user-facing interfaces, yet you can compile them out. (Not just things like ext4; think FUSE or overlayfs, which some applications will build upon and require.) Some prctls are optional, new syscalls like BPF or inotify or process_vm_readv are optional, hardware interfaces are optional, control groups are optional, containers and namespaces are optional, checkpoint/restart is optional, KVM is optional, kprobes are optional, kmsg is optional, /dev/port is optional, ACL support is optional, USB support (as used by libusb) is optional, sound interfaces are optional, GPU interfaces are optional, even futexes are optional.
We guarantee that you can run old userspace on a new kernel, but not necessarily on a kernel built with allnoconfig.
This change only saves a few kilobytes; is that really worth it?
We're well past the point where we can just remove entire drivers or entire subsystems. A minimal kernel takes up hundreds of kilobytes; every kilobyte or fraction of a kilobyte adds up rapidly. Saving hundreds of bytes is worth a minor change; saving entire kilobytes is exceptional. Each of these changes adds up.
Why not just put more RAM and storage into your embedded system?
When you're building millions of devices, saving a few cents on each one can potentially be quite worthwhile. The alternative may not be "add more RAM and storage and run Linux"; often, it's "leave out the RAM and storage and don't run Linux".
Why use Linux for these tiny embedded systems? Why not some dedicated tiny embedded OS, or no OS at all?
(Yes, this gets asked surprisingly often.)
Linux has a lot more longevity and generality than most embedded OSes. Most such OSes are proprietary. All of them lack the range of capabilities, drivers, and general level of code quality and review found in Linux. Most have far smaller communities (or no communities at all).
Why not run an older version of Linux, like Linux 2.0/2.2?
Do you really want to see more systems in the world running ancient and almost unsupportable kernels? Running an old kernel gives up much of the value of running Linux. Many systems will want to take advantage of some of the latest functionality, while omitting other functionality they don't need. People who approach the kernel community and ask questions about ancient kernels typically get told to run a newer kernel; let's not admonish them for wanting to follow that advice.