Did anyone of the critics actually listen to the talk? Or read up the documentation of kmscon? Or at least looked up some facts before posting here? Please do that and most of your concerns will go away. Anyway, I'll try to give some insights here:

Zeroth question: what's a kernel console for?
It serves mainly to two purposes. To provide some booting diagnostics, especially in the earliest phases, before even the INIT has been run. Second, to provide a way to interact with the system when it has not completely booted yet. I'm sure there's more here.
A single slide of the presentation is labeled "What is it used for?". It lists: emergency-console, lightweight-UI, session-dispatcher and more.
KMSCON was designed to fit into these use-cases exactly but also to _optionally_ provide more.

First question: why should we kill the kernel console? To save memory? To make the boot faster? To gain extra features? I'd like to see how these would benefit the kernel and the system administrators.
Again, a single slide is labelled "Linux Console Problems". To name a few problems: UIs don't belong in kernel-space! It's a horrible API, horrible input handling, horrible video output handling, it's _very_ buggy, no-one knows how to fix it, ... and it is missing proper internationalization!

Second question: Multi-seat hardware-accelerated fully-internationalized kernel console? What would it be the plus? The real one, I mean. To enter shell commands in Chinese, Arabic or with proper diacritics? To get super-fast 3D console rendering at (AFTER) the kernel boot? All those "plura" are not less then bullshit in my mind.
As mentioned in the presentation and documentation, all of these are optional. However, lets give some use-cases here:

Imagine you have a multi-seat environment and your xserver on one seat crashed. In this case you want an emergency-console to restart your session. Hence, you want an emergency console on that seat _only_ so you can recover that seat.
If the console is not multi-seat aware, you would have to interrupt _all_ sessions on the system to restart a single seat. Tell that to inter-cafe-owners. Of course, you could also use ssh, admin-seat or any other idea you can come up with. But there are always more than one way to do something...

And if you're still not convinced: If you want fast-user-switching with X you need a multi-seat aware VT dispatcher. That's just a fact. I won't explain why. Feel free to ask if you want to know more.

Similar reasons exist why all the other features were introduced. For instance, 3D acceleration is used to render a console on multi-seat systems where the CPU is _way_ to slow to render many consoles simultaneously. That is, kmscon _can_ make use of hardware-acceleration in situations where software-rendering might be slow. But again, don't use it if you don't want it.

If all that is "bullshit in your mind", please elaborate why...

Third question: what if I have to troubleshoot a system which has not fully booted yet? I mean things like forced fsck, issues with the /etc directory contents and so on. No userland, no console!
Please get your facts right. How can you run fsck if there is no userland? where do you think fsck-binary is executed? In the kernel? No!
To make use of a console you need to run programs. Whether its bash, cp, rm, fsck or reboot, all these run in _userspace_. Hence, you need a running user-space to make use of the linux-console. So please tell me a situation where kmscon is unable to run, but the linux-console can be used to perform maintenance tasks? Please! I'm desperately looking for one. (spoiler alert: there are none!)

If you are talking about boot/shutdown-logs or oops/panic-screens, please look at fblog/drmlog drivers which were written for this exact situation.

Fourth question: You say that code is poorly maintained, right? So why don't you just ... maintain it?
There is a reason that the code is poorly maintained: The code is crap. Seriously, talk to any kernel developer you want. Just two random comments I read last week on google+ from long-time kernel developers:
Dave Airlie: "everytime I read vt.c/fbcon.c code I feel much worse."
Benjamin Herrenschmidt: "I remember when I tried to fix some of the worst locking issues in there a while ago, I wonder if that's what gave me my stomach tumor"

If you look into Archives you will notice that no-one likes working on it. No-one!

And UIs don't belong in kernel-space, so why bother maintaining it? They belong in user-space!

Fifth question: Maybe all this is for mobile smartphones running Linux, right? Please, I need some more details here as I don't get the point.
KMSCON has nothing to do with smartphones.

If the console is in user-space, how can we debug situations on desktop PCs (without the possibility to connect a serial console) where the kernel can't find the initrd or the root-partition, means: no userspace available?
I think I answered that above. If you have no user-space, a serial-console is useless as well. No userspace, no shell, no use. It's that easy. (and the few things the kernel provides that work without userspace will still work with kmscon).

How can systemd help if you either have a system without it or it gets not loaded because of the problems mentioned in the first question?
systemd integration is optional. systemd-logind allows to spawn/manage VTs, but please don't use it if you have no use for it.

Correct, but then you need extra hardware (a PC and/or a console server and/or a serial adapter) in order to troubleshoot a boot process! Serial consoles are quite useful, indeed. Still I don't see the point about killing the kernel console which, I think, shares code with the "other consoles".
If your platform doesn't have a "local terminal" (aka graphics adapter w/ VGA-DVI-HDMI output), then the serial console is the only one option. And it is in kernel space!
Again, please get your facts right. Linux-console, serial-console _and_ KMSCON share a kernel subsystem called TTY-layer. This will always be used and it's not about to be replaced! However, _only_ the linux-console uses the VT layer. Serial-console and KMSCON are totally independent of it and don't share any code with it.

KMSCON tries to replace the VT layer. And _only_ the VT layer.

And again, the serial-console is a kernel-space API but everything that you run in it, runs in user-space! The serial-port I/O layer runs in kernel-space. The TTY layer runs in kernel-space, but saying a console 'runs' in kernel-space is ambiguous and in most cases wrong.

Sorry, I don't understand this. Are you talking about "USB kernel consoles"? I don't mind about console speed. I mind about it being available as soon as possible. And, going back to previous point, you need serial drivers anyway into the kernel in order to have that.
KMSCON can be used for user-interaction in the same situations you can use the linux-console. If you don't believe me, please describe a situation where you can run a command in the linux-console but you cannot in kmscon? Please!

I wish I could get more than guesses. Anything requires effeorts and resources. Do you think a kernel console is useless? Then fight for a complete removal. Otherwise make it as useful as possible.
UTF-8 in the kernel console? I think I missed something. I thought that all internal kernel human messaging was in English with 7BIT-ASCII. My bad!
Yes, the linux-console supports UTF8 indeed. But the font-rendering is limited to 512 different glyphs at a time so you cannot make use of the full Unicode set.

Smartphones do not use X (maybe Wayland in the future) but the frame buffer. I didn't get any possible reasons for getting a userland console in Linux based smartphones, a very peculiar Linux platform...
Some old 'regular' phones did use X (and probably still do). No modern smartphone uses fbdev (Android <=2.3.* used it but now it's obsolete). And no-one is trying to push it into smartphones. I don't know where that came up but it's not related to kmscon.

Stop guessing. I'll try to explain myself better.
I'm just saying that I don't see reasons to move the kernel console out of ... the kernel.
Imagine there would be no kernel-console but only KMSCON in user-space. Could you describe reasons to move it into kernel-space? I cannot.

So if you think all others reasons mentioned in this thread are invalid, how about this reason: It doesn't belong into the kernel. And KMSCON is an attempt to clean-up kernel code and reduce the amount of non-swappable kernel memory (by removing the linux-console).

I say that we do need a kernel console, maybe we need a better kernel console, but that would hardly require hardware acceleration, internationalization and multiple seats.
I say that a kernel console needs to be available as soon as possible at boot. Full stop. Anything else sounds useless to my poor mind.
Once I get the boot done I can use normal pseudo terminals with TELNET/SSH/whatever and even X terminals on both local and network displays. That'd be it.
I think I answered this 3 times above. If you can make use of the linux-console, then you can also make use of KMSCON. In all situations. Otherwise, please prove me wrong.

My side of this argument is that the whole idea is crap. The VTs are only ever used as a last resort, so the simpler they are, the more likely they are to be functional. I don't want them replaced by a feature filled (bloated) userland terminal. Recovery of the system should never require internationalized letters. If you want to manage a Cyrillic filesystem through a terminal, then either fire one up after the boot, in userland, or add support for internationalization alone to the VTs, but simpler is better. This whole idea reeks of unnecessary complication.
Why do you think CONFIG_VT is simpler than KMSCON? Please prove this with facts! If you use kmscon without any optional modules, it is mostly identical to the linux-console but in user-space.

We do need a low level access for emergencies. The simpler, the better. The earlier, the more effective.
Agaaaaain: KMSCON works in the same situations as the linux-console. In fact, it can even work in _more_ situations (like using udlfb when your PCI/embedded GPU hangs).

Practical question, since I am still not getting it. When on a normal desktop PC (no serial console), with the new implementation, the system fails to boot, for example due to a corrupted/missing initrd, would I see the error messages on my physical display so that I can troubleshot the system?
yes, either provided by CONFIG_VT or by fblog/drmlog.

And you know what the greatest thing of kmscon is? It's 100% backwards compatible. So stick with VTs if you love them, switch to KMSCON if you hate them. It's not like _any_ software depends on KMSCON so it's really optional.
But if you ever run into a situation where you'd like to tweak your emergency-console, good luck with fixing VTs. I prefer fixing KMSCON.