AES speed compared to permuted LCG What is the speed of AES and how to estimate it well? Here:
https://security.stackexchange.com/questions/92074/aes-algorithm-encryption-time
they wrote it could be 700 MB/s. But here:
https://www.cse.wustl.edu/~jain/cse567-06/ftp/encryption_perf/index.html
Abdel-Karima Al Tamima estimated it is about 50 MB/s. Why are there such differences? Is it because of some kind of hardware acceleration? I'm trying to compare it to PCG generators:
https://www.pcg-random.org/paper.html
Just to compare what is faster in generating pseudorandom numbers (I know that PCG is not cryptographically secure and it is not a cipher). For example 128-bit PCG XSL RR RR can proceed about 65 GB/s (it was probably implemented in numpy of Python). Is it comparable to 50 MB/s or 700 MB/s?
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.