TL;DR: Those claims do not add up.
The whole issue is, to use nice words, an urban myth. It ticks all the boxes about MS being an evil conspiracy but does not deliver any validation, neither references nor concrete claims making it open to speculation by interpretation.
An API can not be implemented and not implemented at the same time.
Being an API is the key part here. POSIX stands for Portable Operating System Interface and is an API. POSIX isn't some OS or a certain OS or kernel design and especially it's not UNIX. While it's based on Unix and tries to unify the user side API of various Unices, it can be implemented with any OS (*1).
POSIX implementation is also not a name game, but certified against a fixed catalogue. It's a point of existing or not. For that it doesn't count if the POSIX API is the only one available or even the one used most - or in what way it is implemented. No matter if implemented in basic system calls, a system library or a user side library. All that counts is that programs using POSIX functions in a way POSIX defined them can be compiled and executed in that environment.
Not defining the way of implementation is exactly what makes POSIX a portable interface definition.
Windows offers the POSIX API out of the box. The fact that other API also exist is meaningless - likewise what API an application uses. Windows is eventually among the OS least divergent from Unix, considering that true classic mainframe systems with zero commonality to Unix, like OS/390, z/OS or BS2000, are fully POSIX certified since the 1990s.
Windows NT implemented POSIX compatibility because some US government contracts required such.
MS adding it just for "some US government contracts" sound far fetched and more like trash talking than any serious angle. POSIX was a major buzz in professional computing the 1990s. A must for anyone who wanted to stay in Business.
It is said that the POSIX implementation was only pro forma,
Not sure what 'pro forma' could mean in context of an API. Either it is implemented according to POSIX specification or not. There is no inbetween (*2).
Intention is a very debatable point, rather opinion based, without any valid statement of MS themself or reliable proof thereof.
or suitable for real use
Which as well does need at least some reasoning why a provided, certified API should be suitable for 'real' use
(i.e. Microsoft hoped the customer would accept the operating system, and then run NT-specific software, thereby giving them a moat against competing platforms).
What hodgepodge should that be? Requirements are made ant meet, otherwise no procurement. So the question is not what MS hopes, but what the requirements are. Was there a requirement that some application, provided by MS uses that API, or was it that the API should be present? In the later case, it doesn't matter what API the application software uses. Hard to see anything relevant here.
In what specific ways was the POSIX implementation unsuited to real use?
That's an extreme assumption without any source and specification.
*1 - Provided that OS does offer the basic capabilities the API requires.
*2 - No, implementing only parts (like .1 or .1a, etc) is still implementing and valid for certification.