We can have Findmlpack.cmake, but the problem is that it is not usable in the cross compilation steps.
If you want to have it independently, sure, we can create another tutorial for using cmake and mlpack in a normal project. However, when it comes to cross compilation, I would prefer to use the auto downloader on mlpack to avoid any confusion with the system /usr/includes.
For instance, it will be very hard to make Findmlpack.cmake be sure that it is not in /usr/include or /usr/local/include and if Findmlpack.cmake return true when doing cross compilation, we have a high chance that the entire compilation will fail.
Findmlpack.cmake is a nice addition to make it simple for users. I myself would go into the direction of simplifying the entire process. Users only need the headers and they only thing that matters to them to have them in the target_include_directories. They can point them out by themselves or use Findmlpack.cmake. However, this should be avoided in the case of crosscompilation

With all CMake find_package() scripts, you can specify directories to be searched. So you can, say, autodownload Armadillo and compile OpenBLAS, then set ARMADILLO_INCLUDE_DIR before calling find_package(Armadillo) and wherever you downloaded it will be searched first. The same with mlpack, cereal, ensmallen, whatever. So a Findmlpack.cmake script doesn't rule out using the autodownloader---it's just a convenience to find all the dependencies in whatever search path was specified. Setting cross-compilation options is something that's orthogonal to finding the dependencies.