Though using the vs2015 toolchain (and therefore visual studio c runtime) is a somewhat viable workaround, it's not preferable because C++ is moving pretty quickly nowadays, and continuing to use an old toolchain locks your program out of features, improvements, and bugfixes in the more recent compiler builds.
If you do forward your program toolchain to the newer version and attempt to link a vs2015 pre-built library into a vs2017 compiled program, you end up with multiple instances of the c runtime running the process at once. This in turn can create classes of bugs that it's best to not be saddled with. One example of this is multiple instances of the C++ default heap allocator (per-runtime). This means that an object allocated via the vs2017 c runtime's 'new' can't be freed by a call to the vs2015 `delete`. Each runtime allocates it's own heap handle via ::CreateHeap (or does it's own heap allocator).
Typically updating a library to a new version of the compiler and runtimes involves minimal effort, so having the existing release made available when a new release happens is ideal.
Having used FBX in an open source engine for a couple years now FBX tends to be the last pre-built library to make builds for recent compilers and runtimes available. Putting this on the roadmap would certainly make FBX a more attractive competitor to what is becoming a more alternative-rich arena.
