Hey, Ryan. I’ll chime in to say that I am not seeing what you do. For that earlier Q of Q, I see lines written to the application.log, which start with:
"ERROR","http-nio-8888-exec-3","01/07/2022","16:10:20","",";lucee.runtime.exp.DatabaseException
Column not found: FOOTYPODOESNOTEXIST in statement [SELECT fooTypoDoesNotExist FROM myq];lucee.runtime.exp.DatabaseException:
which is indeed the same error that showed on screen. Same with your last example here, when I referred to a non-existing var:
"ERROR","http-nio-8888-exec-5","01/07/2022","16:11:24","",";variable [X] doesn't exist;lucee.runtime.exp.ExpressionException: variable [X] doesn't exist
So I wonder: might you have error handling enabled? Even with ACF, if an error handler intercepted an error, then that error would NOT be logged. This is true whether using try/catch, app-level, or site-wide error handling.
And in fact, I did a blog post trying to encourage folks to always add a cflog/writelog of the error to the application log, whenever they DO enable error handling, especially if they just shunt off an email or write the error to a db. This way, others looking at the log COULD know that the error WAS happening. 
If you would say you are NOT doing error handling (of any kind), then I’ll just repeat how my testing of your examples DOES write to the applicationl.log. Perhaps there could be some other environmental difference to explain your observed behavior.
All that said, I can concur that those error messages above lack some of the info that CF errors in the same log would have. That said, those errors are not always accurate in their indication of the template and line number, right? I would often point folks in that situation to that very exception log, where in CF it would show the stack trace for the request in error, and that WOULD tell us the EXACT template and line number with the error.
Well, note in this case that the Lucee devs opted to put that stack trace IN the application.log (and also the exception.log). I didn’t include that above (as it’s about 50 lines), but note that I said the log lines STARTED with that line I showed. So granted, that info in the application.log in Lucee is not as “simple” as CF’s error line, and it may tend to fill that log faster :-), but it may well be better for those who might leverage that stack trace to find the exact line and template in error.
Indeed, for those who may see this and be intrigued but don’t look at stack traces often (I did a preso on that many years ago), note that in my case the line within the long stack trace which tells me what line of code the error was on looked like this:
at tests.errorloggingtest_cfm$cf.call(/tests/errorloggingtest.cfm:11)
See the path in the parens. And in my case, that at /tests/errorloggingtest.cfm was in my C:\lucee\tomcat\webapps\ROOT, as that’s where I put Lucee (and I tend to use that folder for my lucee testing rather than have IIS or Apache setup to talk to Lucee.)
Hope that helps. But Ryan, I am especially curious if you may have an error handler blocking this logging, or we’ll figure out the environmental difference.