It is true that there are many hard-coded (by the installer) references to the directory path.
Many of these are XML files that contain initial values that are updated under normal operation of CFMX.
Others reference the JVM which is is installed as part of the CFMX install. In our startup shell, we bypass this JVM to use the one that is part of Mac OS X -- this makes any changes to files regarding paths to the JVM unnecessary.
The wwwroot/WEB-INF/cfclasses/ directory is where CFMX stores the templates it has compiled from CFML to Java classes -- these are generated every time a template is changed (or if a Java class for a template is not found) -- so any changes to these should be unnecessary.
However, it is safest to mirror, on OS X, the directory path used to install on Linux.
The delay when a CFMX template is hit for the first time (and after any modification) is as you stated to:
1) Generate Java source code from the CFML
2) Java Compile the Source code into a Java class file (bytecode)
3) JIT compile the bytecode into an executable
4) Cache the executable.
This only happens the first time a template is hit or after a modification -- so it will have little effect in a production system.
It is, however an issue with developers who are changing templates all the time.
There are several ways to work with this, so the delays are tolerable:
1) modularize your code, using the various features of CFMX, so that changes are localized to fewer and smaller templates. For example CFMX has the concept of a CFC (ColdFusion Component), where a group of related functions can be packaged as a separate module (a CFC) and invoked from other CF templates. So, you could code your business logic or database interface as CFCs. Presumably, these would rarely change. Your presentation logic, which is is more like to change, is smaller (no business or db logic) and compiles faster.
2) after changing many templates, batch compile these -- the CF-TALK list has included several threads about this.