[enoren]

This assumes though that you only have a single log. Often times I find breaking up logs based on concerns/packages/names or even level to be useful, which you could not do without reinventing the wheel of output filtering.

This also assumes that anyone is actually really reinventing the appenders as most frameworks already have a library of common appenders.

[imbriaco]

I would argue that you want to do the filtering at the aggregation layer and not at the application level. So while you may want to set different flags or parameters that will be logged (ie: severity, component, etc) those parameters should be injected into the log stream rather than to alternative streams. Let the aggregation point use those clues to filter the logs appropriately.

[prodigal_erik]

If you have multiple streams, you can give lower latency or better durability to critical or low-volume messages.

[encoderer]

This should definitely take place at the aggregation level. There are great tools for this already. This is definitely an implementation detail we developers should delegate to the systems guys.

Not to mention, it's just less development work to send out messages with, say, different syslog levels and be done with it.

[imbriaco]

You can do the same thing with the local or aggregation tier syslog daemon if desired.