You are correct that most DBP functions are not actually asynchronous. However, certain functions that are known to be safe can be identified as "NoSafeCall" in the code templates and are exempt from the thread safety code. Specifically in PureGDK, the 3D Math and most of the Input library are known to be safe.
Locking synchronization on the entire engine instead of a specific code block is simpler to implement if you want immediate results. But there isn't anything to stop someone from disabling the built-in multithreading and implementing their own.
Another advantage of PureGDK is thread-aware error handling. A specific error that occurs in one thread remains known despite other errors which may occur in other threads. Additionally, runtime errors in the engine do not halt the program, as it does in DBP.
I don't know exactly how DarkGDK works internally with runtime errors, but from what I do know about DBP's error handling, it's more like C's "errno" which can return unexpected results in a multithreaded application.
PureGDK is unique in that it was designed with thread safety in mind from the ground up.