The folks at Microsoft wrote Windows itself using the C/C++ language. Therefore the Windows 32bit Application Programming Interface (Win32 API) is tightly linked to the C/C++ language.
That means, in order to use the Win32 APIs, VB.Net programmers must be able to read the API documentation and translate that information into something that VB.Net can understand.
Note: VB6 had a utility that would generate the API declarations for you... I have *no idea* why Microsoft decided to not include a similar utility in Visual Studio .Net.
From a .Net perspective, all of the Win32 API is considered "unmanaged code". When VB.Net makes a call to a function inside a Windows DLL file, it uses a technique called Platform Invoke (often shortened to P/Invoke) to pass information to and from the API.
There is a substantial performance hit for using P/Invoke because of the tremendous amount of work that goes on by the scenes copying data back and forth. For that reason, you should always use the "native" .Net functions (if available) over the corresponding API functions. However, the "native" .Net classes do not cover a lot of the things required by an application that performs low-level functions. So, in that case, using the P/Invoke with a Win32 API is the only option available.