My previous patch didn't take into account if a literal comment started with a
'#' or ''' which are valid starters for some elisp expressions. I have now
updated my patch so it checks those as well. Naturally a literal comment can't
start with an '(' as a first non-white character. As I am aware of that is the
only limitation for literal comments. I don't think that would be a deal
breaker. Maybe there are some other places that breaks, that I am not aware of
since I am not good with elisp.

I have tested with org files as well to see if my theorycrafting holds, and it
does (mostly). I was able to evaluate my init file which is several thousands
of lines org file full of elisp (use-package & Co) without entangling it. I
have also tested some simple org feature (code folding) in ordinary elisp and
it also worked as expected. I do get an error message when I load org-mode into
elisp file: "helm-M-x-execute-command: Symbol’s function definition is void: fn"
if I load manually, or if I load org-mode with comment line at the top:
"File mode specification error: (void-function fn)".

However, despite those messages everything seems to work as expected, so I am
not sure about how to deal with those or why do I get them. I get this even when
I load my init.org, but org-mode seems to work normally when I try to edit it.

As a more polish, I think it might be nicer one had buffer local variable to
enable/disable literal comments so that both byte compilera and read-eval loop
could use it. One could then make minor mode to turn literal elisp on/off per
buffer or globally as is usual emacs way of doing this.