AES is generally very fast when implemented in hardware. On my laptop, a Core i7 8665U, AES-128 operates at 6758 MB/s. It is slower when implemented in software, and it is much slower when implemented in software in a constant-time implementation. A naive software implementation that is not constant time runs as 367 MB/s on my system.
You mentioned that you're looking for smartphone processors. Some of the newer processors will have AES acceleration available, but not all will. If you're looking for an algorithm that will perform well on almost all systems, be constant time, and cryptographically secure, I'd recommend ChaCha20, or, if you really need screaming performance, ChaCha12. ChaCha20 on my system runs at 3513 MB/s and will clearly outperform AES where hardware acceleration is not present. ChaCha12 performs almost as well as or better than many non-cryptographic PRNGs. It would be my choice for a PRNG, whether cryptographic or non-cryptographic, because it is fast, secure, and has no weak seeds (unlike many non-cryptographic PRNGs). It is also the default PRNG for the Rust
rand family of crates, and ChaCha20 is used in the Linux kernel to generate random numbers.
Note that any performance comparison of PRNGs also has to consider not just generating the values but getting them into a place where they can be used. For example, AES-NI instructions would probably perform even better than I listed above if you only encrypt the same data in place using vector registers. However, the performance drops off when you must load and store data to and from memory because that is more expensive. I suspect the PCG paper does not take that into account in a practical way.
Of course, performance measurements on my system are not reflective of other systems and if you need to know how things work on a particular system, you should benchmark it yourself. You may also want to look at SUPERCOP, which benchmarks many cryptographic primitives on various types of hardware to answer your questions. It's likely that you'll find hardware that is comparable to modern and older processors, including a variety of ARM and ARM64 hardware.
A final note about performance: you don't always need to use the fastest algorithm for a job. It is likely that in most applications, the generation of random numbers is not the bottleneck, and the benefits of using an algorithm like ChaCha (such as its lack of weak states and better quality) may outweigh the fact that it is slightly slower. Your benchmarking would need to focus on identifying places that are a bottleneck, and improving those whenever possible.