In conversation with Lennart Poettering, systemd developer Zbigniew Jędrzejewski-Szmek's position was to turn the mechanism on and gather statistics about who and what it broke.
Lennart Poettering did this about 20 hours later.
Within a week, this was in the released version of systemd.
Their position has been since that the correct thing to do if one hits this is not to revert Lennart Poettering's change to the DefaultTasksMax and DefaulTasksAccounting settings, but to tweak the service unit files of any and all affected daemons.
The systemd bug report paints this as an Ubuntu problem, in part because the systemd developer who submitted it is also the Ubuntu maintainer for systemd, but there are actually quite a lot of bug reports across several distributions that relate to this.
Several people have simply placed TasksMax=infinity in their service unit files; but a few have indeed reverted the DefaultTasksMax setting, as the Ubuntu maintainer also asked for.
The maximum applies to kernel "tasks", not to processes.
So whilst one can hit it by forking a lot of processes, one can also hit it with only a few processes that happen to use a lot of threads per process.
This is of particular concern to MySQL, MariaDB, Percona, and their ilk, which use a thread per client connection.
As Brad Mashall discovered, the effect is that the SQL servers start refusing client connections.
Someone hit this with a multi-threaded Java program and reported it to Arch.
The issue was clouded by two things:
First, it was obscured by another systemd issue that imposes a task limit on every user service spawned by a user's per-user instance of systemd.
Second, it was obscured by the complication that GNOME Terminal does not spawn terminal instances directly but rather uses Desktop Bus to spawn them remotely via "DBUS activation", resulting in terminals and the processes in their associated login sessions having the non-login-session task maxima applied.
Others have reproduced this with lots of processes.
Dominique Leuenberger reported to OpenSUSE that this affects a lot of xyr builds because of parallel make.
Gustavo Romero created a short makefile to use with parallel make (make -j500) that exhibited the problem.
Marko Mihovilic reported to Arch a similar problem on build machines.
Jakub Sztandera reported to Arch that LXC encounters this limit.
Other people observed there that it has affected Java services such as Freenet.
Lennart Poettering reiterated that people should not revert his changes but instead change their individual TasksMax settings.
It affected Docker, and this was reported to RedHat.
The Docker people then noticed that all of the people who had CentOS 7, Debian 8, and the like were seeing a message about an unknown systemd service unit directive.
Others (including Nathan Cutler, who reported the systemd problem to Ceph) had seen this, and after discussion considered it cosmetic, as it did not in fact prevent services from running on older versions of systemd.
The Docker people, however, promptly reverted their fix.
The Docker position is now that "people on newer kernels" have to maintain their own specially tweaked versions of systemd service unit files.
It hit Azk, too.
Sebastian Schmidt hit this with Chrome, where the entire session spawned by xdm was limited to 512 threads in total, and reported it to Debian.
Breno Leitão hit this on Ubuntu, with the SSH server under one set of control groups on one system and under a different set on another, the result of a dependency chain involving PAM and PolicyKit.