The phrase I would use would be "choose files over database tables". That isn't slamming the door on using tables, its just saying that in most cases would be the preferred choice.
Indexes for common use cases? That's the thing, the common use cases are un-indexable unless you count full text searches. There's a reason why people use Elastic Search, Logstash and Kibana!
The main issue for me is that a huge percentage of what is in a log is noise. We incur IO cost to store, back up, ensure availability for logs which are bulky but with a low percentage of relevant data.
Security. Putting stuff in log files that has security implications doesn't feel right.
Logs tend to be semi-structured. Bunging the message in a VARCHAR(MAX) is as much as most people will do.
If you need to track for security purposes don't call it logging, call it security tracking and design for that use case.
I know of one project where, due to security requirements, 50gb per day of logs were captured. As long as they were captured security were happy. The fact that security didn't have the tools to query the logs didn't seem to worry them. For all they know rhe logs could be full of "Security guys are the Window of No" repeated over and over again!
I think we have to ask ourselves what value does an RDBMS add to a particular use case? If we have finite resources would we squander those resources on this use case? Where is the ROI?
Do I want to sweat blood keeping a system up and running because a logging system is hogging resources such as SAN space?