Basically the idea behind the generic structured logging
framework (the perf events kernel subsystem) is to have
both ASCII output (where desired: critical errors), but to
also have well-specified event format parsable to
user-space tools.
Plus there's the need for fast, lightweight, flexible
event passing mechanism - which is given by the perf
events transport which enables arbitrary size in-memory
ring-buffers, poll() and epoll support, etc.
perf events supports all these different usecases and
comes with a (constantly growing) set of events already
defined upstream. We've got more than a dozen different
upstream subsystems that have defined events and we have
over a hundred individual events. There's a rapidly
growing tool space that makes case by case use of these
event sources to measure/observe various aspects of the
system.
Regarding dmesg, there's a WIP patch on lkml that
integrates printks into this framework as well - makes
each printk also available as a special string event.
That way a tool can have both programmatic access to
printk output (without having to interact with the syslog
buffer itself) - together with all the other structured
log sources, while humans can also see what is happening.