The main problem is the literal definition of 'emulate' in this instance contradicts the computing definition a bit. To emulate, is to imitate. WINE does exactly that
See this isn't really true either; WINE isn't exactly "imitating" these APIs either, what it does is provide native Linux/Unix APIs that conform to existing Windows APIs. While Windows executable running via WINE may not notice the difference because they haven't been written to do-so, but they could be if they wanted to know the difference.
Even when you select compatibility modes for WINE (e.g- Windows XP, Windows 7 etc.) you're really just tweaking the exact version of those native APIs, the features that they implement and the behaviours that they implement in order to conform to what a program might expect.
While you can argue degrees of mimicry, the fact is that WINE is not actively pretending to be a legitimate copy of Windows, but instead is simply providing Windows executables with the APIs that they need in order to run.
In true emulation you are running an actual copy of Windows (which WINE does not require) within a virtual machine that's actively pretending to be genuine hardware, despite actually sharing hardware with another host OS. To both Windows and your programs the virtual machine is a legitimate PC, WINE does not provide that.
The most fun difference between WINE and emulation is that software running under emulation is universally worse than running natively under the same guest OS, even if it's just a tiny performance difference that you won't really notice. However programs under WINE can actually run better than they would under Windows; this is the case with Skyrim which can actually run provably better via WINE under Mac OS X than it does when running under Windows under emulation, and even runs better (for me at least) than restarting into Windows 7 to run it natively, albeit without true controller support as I don't think anyone has really been working on that for WINE.