It's a simple way to do it - I think usually a good stack trace for errors or a debugging environment which allows break points might cover most of this functionality and give some other information a simple console.log would not give you.
That being said, I like the idea of tracing information the developer specifically thinks is relevant as its called and having it logged out.
For errors I'll always log the full stack trace (in JS, at least). This helps a ton for when errors occur, but I find that often times it's not explicit errors that are a problem (e.g., making sure the right message is sent and received from a queue system). Of course, setting breakpoints can give more information, but it's not always obvious where a breakpoint needs to be set (e.g., when a new person comes on the team) - for me, logging points me to where I need to set breakpoints, speeding up my development time.
That being said, I like the idea of tracing information the developer specifically thinks is relevant as its called and having it logged out.