I’m not sure how to interpret the “are not officially supported by the OCaml compiler” wording. In my interpretation it is simply not true. The OCaml system compiler supports mli only modules, uses them itself (or at least used), and will always support. Ok, the last could be an overstatement, as there is no legal bonding that will enforce OCaml developers to keep things as they are. So they may change whatever they would like. Maybe this is what “official support” meant 
The mli only modules are indeed a little bit confusing and people are arguing whether it is worthwhile to have them at all. To understand them we need first to understand how OCaml compiler translates source code of a program into a binary (or bytecode). A program in its source code representation consists of types and definitions. Types are instructions to compiler, that constrain possible interpretations of definitions. Types are used for checking that a program definitions are consistent and for generating efficient machine code. The types are erased when a program is translated to the machine code by the OCaml compiler.
The OCaml compiler implements a separate compilation system, where each file is compiled into a compilation unit and then all compilation units that constitute a program are linked together into one big executable or archive. Compilation units contain only machine code, if you will create a file that doesn’t have any definitions, but only types (your typical _intf.ml file), the resulting compilation unit will be quite bogus, it will contain only one function called the entry point, which will have the following, pardon my x86, code
camlExample__entry:
movq $1, %rax
ret
In other words, it will contain 9 bytes 0x48,0xc7,0xc0,0x01,0x00,0x00,0x00,0xc3, again sorry for x86, which will be automatically executed by the CPU when your program is loaded. Ok, there will be also some overhead during dynamic linking, as the camlExample_entry should be relocated and put into the symbol table.
However, we don’t need to pay this price, since types do not have runtime representation why do we need to create code for them. Indeed, the compilation system doesn’t require it. When you reference a type (or modtype, or class type) you are using the dot notation, X.elt, and what compiler is doing, and this is well documented and supported, it will look for the x.cmi (or X.cmi) file in the search path, which starts with the local folder and is controlled with the -I argument. CMI files, which stand for “compiled module interface” files, serve as repositories of types and are used only during compilation. They are of no purpose at runtime and therefore are never linked into the binary. However, when your binary is a library, those cmi files provide means to access definitions in your library, so they have to be installed if you want others people to be able to develop their own applications that use your library. They serve as .h files in C runtime, except that OCaml will not allow you to access a value in a library if you don’t have the corresponding cmi file. But for the runtime and linking (even dynamic) there are still not needed, only for compilation.
Therefore, the idea was, why should we pack our types in compilation units if we don’t need to. Instead, we can put our type definitions into an mli file, compile it to a cmi file and let the compiler to read our types from it. This will reduce the linking time, loading time, and startup time. Negligible, but still neat.
Of course, the build automation system has to provide some support for it, e.g., it should not try to find a corresponding ml file, it should install it along the rest of the library interface, and so on. There is also a small problem with module aliases, which, depending on whom you are asking, could be seen as no problem at all, a bug in the compiler, a problem with mli only files. I personally, treat this as a not-a-bug and not-a-problem. Just a little bit of abuse of syntax, introduced with module aliases, which is confusing.
To summarize, it is safe and ok to use mli-only files, if you understand what they are. And now you are. You won’t win a lot from using them though. Like a little bit faster linking time, smaller binaries, faster startups, and, the most important, awe from young programmers