Log structurally, have option for human readable output is probably the sane default approach here. Sometimes you just want to run an app from commandline, send a request to it and see what happens
I could go either way on making it optional. I try to avoid configuration complexity and the log format is a piece of complexity that can be removed from your application with post-processing.
For example, I wrote opinionated-server which lets you pick text or JSON logging. Even though it has text logging, when I'm developing a server locally, I just pipe the JSON through jlog because I have super-refined that format to my personal tastes, whereas zap's builtin text format isn't as nice.
But I will say that when I create loggers for unit tests, I use the text formatter if one is available. I have never been interested in parsing JSON logs interspersed among plain text (though it is totally very possible to do).
I always liked structured logs because it frees my mind from coming up with how I want to format arguments. "New HTTP request for /foobar from 1.2.3.4 with request-id ac31a9e0-5d57-44de-9e98-60fa94d3e866" is a pain to read and maintain. `log.Debug("incoming http request", logger.IP("remote-ip", req.Address), logger.String("request-id", req.ID), logger.String("route", req.Route))` is easy to write, and the resulting logs are easy to analyze!
I do like myself some pretty colorful logs, but prefer JSON as the intermediary. It's pretty easy to post-process the logs into something understandable. I wrote https://github.com/jrockway/json-logs for this task. Give it a stream of JSON logs, get colorful text out. Add/drop fields or select/highlight interesting lines with JQ or regular expressions (with -A -B -C of course). Installable on Linux or Mac with Homebrew ;) It's one of the few pieces of software I wrote for myself that passes the "toothbrush test". I use it twice a day every day. And that's a good day when I'm not pulling my hair out over an obscure issue ;)