What I don't understand why or where you would use this .h file.

It can't be part of an end-user application, because looking for Visual Studio on an end user's machine is futile.

Maybe if you're writing some kind of extension for Visual Studio?

The comments in the header point to some lack of understanding on the author's part:

  // HOW TO USE THIS CODE
  //
  // The purpose of this file is to find the folders that contain libraries
  // you may need to link against, on Windows, if you are linking with any
  // compiled C or C++ code. This will be necessary for many non-C++ programming
  // language environments that want to provide compatibility.
  //

This needs to clarify the exact situation. Because the normal end-user application cannot be looking for Visual Studio materials. It is completely wrong-headed. They either do not exist, or else were installed by some other application, almost certainly in its own folder. (On this side of year 2000, no application installer should be putting libraries into a system folder.)

The folders that contain libraries you may need to link against are found by default; you don't have to tell your program where to look for user32.dll or kernel32.dll.

Any non-system library is in your own folder: you ship that library with your program, and it goes into C:\Program Files\YourProgram\bin or whatever.

Any .DLL files which are in the same folder as your .EXE will be found by it automatically; there is no need to write code to look for anything.

// We find the place where the Visual Studio libraries live (for example,

That place is nowhere, on 99.999% of the installed Windows machines on the planet.

Unless you mean some other application's C\Program Files\OtherApplication\bin folder, where you have no business looking or using.

  // libvcruntime.lib), where the linker and compiler executables live
  // (for example, link.exe), and where the Windows SDK libraries reside
  // (kernel32.lib, libucrt.lib).

kernel32.lib is a kind of liking stub; the library per se is kernel32.dll, which is a system component.

.lib files are not even required for using .dll files; for instance, you can use .dll files via dynamic FFI in various languages, without a .lib file.

Projects built with Visual Studio generally not have to worry where kernel32.lib has been installed; the tooling takes care of that. Programmers don't have to specify that themselves in project files.

It could be a concern if you use some external build system; it would then need some configuration mechanism to point various toolchain-related variables at all the correct directories. A program using "microsoft_craziness.h" could be built which runs on the that build machine and produces a batch file full of environment variable assignments, or whatever. That I can see.