Arch Linux

I personally despise security through obscurity, so I am strongly against adding that to /etc/sysctl.conf; the cheap sense of security this brings to your system is simply not worth anything.

If you feel otherwise (and are compiling your own kernel, obviously), feel free to use the /etc/sysctl.d directory.

I'm sorry but I have to disagree. This isn't security through obscurity but simply a mitigation technique that can make kernel exploitation harder in some cases.
By your reasoning, any mitigation technique, like ASLR or NX, should be disabled because it merely makes exploitation harder without fixing the bugs, but (security) bugs in software will always exist and can't always be fixed in a timely manner. So even if exploit mitigation techniques like this one are rarely perfect or always effective, this isn't a sufficient reason to dismiss them.
You say that people compiling their own kernel should enable this option themselves, but you have to know that most of them won't do it, either because they don't have the expertise to know such an option exists or don't understand the security benefits they could gain by enabling it.
In the end, it's also the distro's responsability to ship with sane values enabled by default...

When this request was made, I googled for possible downsides. So far the only tool that breaks by enabling this is perf, which needs access to kernel symbol addresses to work, but as you can run perf as root only, I don't see a big problem with that.

Other distributions are enabling this by default also, so I don't think it's bad to enable this.

The current situation is the sanest: as you said yourself, it is pointless to hide kallsyms for a precompiled kernel, so we leave kernel.kptr_restrict to its default value and let /proc/kallsyms available to whatever programs can make use of it (even if there are only a few).

Deviating from upstream default values goes against our core principles, and is particularly bad when this brings no benefit to our packages.

When you compile your kernel with non-stock configuration, you are expected to update related configuration files yourself too. This is a basic rule which, in fact, applies to all packages. We are simply not going to ship home-made configurations that try to guess what people who recompile their packages might do or want.

I also want to comment specifically on hqet4's sentence: "people compiling their own kernel should enable this option themselves, but you have to know that most of them won't do it, either because they don't have the expertise to know such an option exists or don't understand the security benefits"

This is not Ubuntu. People who recompile their own kernel should really know what they are doing. We have no duty to protect people who are ignorant yet modify core parts of their systems. Besides, in the worst-case scenario, they would not be at any more risk than stock kernel users.