Why doesn't FreeMarker allow templates unrestricted access to Java reflection and side-effecting method calls?

This is a deliberate security boundary, separate from the general design-philosophy reasoning behind FTL's restricted syntax. If a template - which may come from a less-trusted source such as CMS content or a customer-editable theme - could invoke arbitrary Java methods through reflection, it could just as easily call something like a process-execution API as it could call a harmless getter.

FreeMarker's ObjectWrapper is the actual enforcement point: it decides which properties and methods of a wrapped Java object are visible to template expressions at all, and a more restrictive wrapper such as SimpleObjectWrapper exposes far less than DefaultObjectWrapper does. Static members and enum constants are not reachable from templates by default at all - they must be deliberately exposed, typically via BeansWrapper.getStaticModels() - and a TemplateClassResolver can further restrict which classes a template is even allowed to name. Raising incompatible_improvements can also tighten some of these defaults over time without silently changing behavior for applications that have not opted in.

In short, the safety comes from what the application chooses to expose through the wrapper and resolver settings, not from any restriction baked into the FTL syntax itself.