TL;DR - Quick and Easy
Here is a free unity asset store package that claims to do exactly what you need. I haven't personally tried it, but it (or another like it) might solve the issue you are looking for specifically.
Why can't I use the code that obviously already exists?
It's important to remember that when you add an asset to your unity3d project, that isn't the data that ends up in the game's asset bundle to be loaded and used by the engine. The editor converts the file into a friendly format for simulation and rendering - as opposed to a convenient format for transport. For reasons I can only speculate (I am not a unity developer) they did not package these in the final runtime application (the version of the game you ship) so you cannot access them. It's possible that it is some combination of licensing (for things like FBX), binary size (adding a bunch of libraries, code, and code paths that would bloat most games), or some deeper technical hurdle where the cost wasn't worth the benefit.
Another consideration is that it's not just meshes that need to be imported, but textures, materials (and then shaders), and animations. Dragging and dropping a model (in my experience) is rarely the only step involved in getting an asset from disk to game. Perhaps the developers thought that since they could not make a clear, precise API for users that it wasn't a feature worth adding (no support for a feature is often a better choice than a half baked, bloated, confusing one - certainly QA / Customer Service / Technical Writers must think so!)
From File on Disk to Asset In Game
Here's a really rough, naive guess at the steps involved in getting a file off desk and into the game:
Pick a model format you wish to support.
Parse the file, and build a heirarchy of meshes / sub meshes / skinned meshes from the verts, also making sure to load the bones and default bind pose information. This API is available (ie: procedurally generated meshes: https://docs.unity3d.com/Manual/GeneratingMeshGeometryProcedurally.html )
For each submesh, load whatever material data is supported in the mesh.
Using data from the file locate which textures and maps are used.
Have a fixed number of pre-determined materials in your game that you map to materials applied to the submeshes in the model.
Apply the mesh / skinned mesh to the appropriate mesh filter / mesh renderer.
Apply the appropriate materials to the mesh renderer
Apply the appropriate material parameters to the materials.
As you can see, unity asset pipeline API would only get you 1, 2 and 3. 4 debatably (personally, when I bring in a mesh it never applies materials properly, often times it doesn't even load the textures properly). The rest is done at design time by hand, so you'll have to figure out how to do that in code in a way that works best for your project. This isn't even touching on things like Mechanim trees, optimal texture format compression, generating mip maps, etc etc.
So how do these plugins work?
My guess (not having used them or look at the code) is they do the absolute minimum amount of work. They support only a very specific model and version format, and only mesh and texture data. They assume you will just apply a single material or create a material using some default shader and settings, which might work for you but for most games this treatment would be insufficient. They also likely only support the legacy animation system, if they support animations at all. Likely they will do their best to make things look as default as possible, or ignore / skip settings that are inconvenient or difficult or impossible to tune without an artists eye.
I can attest that whatever they are doing most likely wouldn't pass muster with a discerning artist, but maybe that isn't a problem for your particular use case.