The solution turned out to be to pass intel_pstate=passive to kernel. Then intel_pstate relinquishes control back to CPUFreq. The latter still uses intel_pstate to govern the CPU, but intel_pstate has no say in what to do. After that, you can finally set performance policies. Your laptop can be either completely quiet or you can make it very noisy, but powerful. When intel_pstate is active, the machine is neither quiet nor well performing, but rather always slow and noisy.
Two years later update
It turned out there is more to the story. The computer in question was a Gigabyte laptop. When I got a new laptop, also from Gigabyte, a trick with intel_pstate=passive didn't help. I started digging deeper and found out that (i) Gigabyte's firmware limits the performance if the laptop is running on anything but Windows. ACPI knows the OS it is running on via _OSI. Not only that, but you see, usually laptop manufacturers contribute to the Linux kernel and write a small driver, specific to the vendor, that helps to monitor the system and manage the performance. If you look in the kernel source code, you will find a lot of them in drivers/platform/x86, for Dell, HP, ASUS, Lenovo, Fujitsu... Well, (ii) Gigabyte has done nothing on this front. The first problem can be solved by passing acpi_os_name="Windows 2015" to the kernel. The performance will become better. However, to really make a Gigabyte laptop usable on Linux, somebody has to write a kernel driver for it. There is a user-space workaround, used in this project, that utilizes a debug feature of the kernel and writes value directly to the embedded controller registers. It's dangerous and requires undocumented information about the EC. What one should do instead is to call WMI's ACPI methods from the firmware.