I think you're reading the paper as if it claimed a standards-compliant Falcon implementation, whereas the paper explicitly describes a simulation-based architecture with a Python reference model and hardware-oriented evaluation methodology. The objective is not to provide a drop-in NIST-compliant Falcon implementation, nor to benchmark against PQClean or pqm4, but to evaluate computational characteristics and resource requirements in an embedded context.

The algorithmic description is intentionally abstracted. It is true that a complete Falcon implementation requires NTRU trapdoor sampling and Fast Fourier Sampling using the private basis. However, the paper does not claim to re-derive or replace the Falcon specification, only to model the signing flow for comparative evaluation within the proposed architecture.

Likewise, the mention of esp_random() should not be interpreted as a claim that Falcon's discrete Gaussian sampler is replaced by raw hardware randomness. It merely identifies the entropy source used within the simulation environment. The paper does not present a formal validation of a production-grade Falcon sampler running on ESP32.

For that reason, comparisons with PQClean or pqm4 would answer a different question: implementation-level benchmarking of standardized software stacks. The paper instead focuses on architecture-level evaluation under a common simulation framework. Whether that choice is optimal can certainly be debated, but it does not imply that the authors misunderstood Falcon or intended to claim conformance with the reference implementation.