I am not sure what you mean by "standard" SSTP - but when connecting from a windows client it will not do so without the cert installed in Windows.
...
I guess at the end of the day my confusion stems from the fact that all I need in the Windows VPN connection is the cert, the username and the password and it works.
SSTP is a VPN protocol designed by Microsoft, hence the "standard SSTP" is the Microsoft implementation of it.
The idea is such that when the client connects to a server, it must get a strong proof of the server's identity, to prevent connecting to a counterfeit server and either getting tunneled through it to the real one, providing the plaintext context of the session to the attacker, or at least disclosing the username and password to the attacker. Hence the server must present a certificate signed by a certification authority trusted by the client (which means the client must install the certificate of the authority in its trusted CA store) and prove that it is the rightful holder of that certificate. Since the client would drop a connection to a server that doesn't present a correct certificate (valid, signed by a CA trusted by the client, proven to be held, and its subject matching the fqdn or address towards which the client has initiated the connection), the username and password will not leak to a counterfeit server (unless someone manages to take over the real server or get its certificate including the private key).
Mikrotik's SSTP implementation has added more possibilities and finer control - the Mikrotik client can also authenticate itself to the server using its own certificate rather than username&password (but the server must support this method, so it must be a Mikrotik server), and on the other hand, the Mikrotik client may be set to skip verification of the certificate subject (so any certificate that is valid, held by the peer, and signed by a trusted CA is accepted), or even skip the whole certificate authentication of the server. The latter is totally insecure but in some cases you've got no choice (mostly when resolving configuration mistakes or expired certificates).
I believe you are right about the "private" key but confused as to how it is working in Windows without it, but not in the MikroTik.
The private key to the certificate is needed by the holder of the certificate, as the way it proves to the peer that it not only has the certificate but also that it is its own one by encrypting a small portion of data sent by the peer using the private key and sending them back; the peer then decrypts that data using the public key that is part of the certificate contents. The basics of this is that you can not derive the private key from the public one (using tools available today and in a reasonable time). So a client needs its own certificate to authenticate itself to the server, hence it needs the private key for that own certificate. But my understanding is that if the server is set to authenticate clients using certificates, the Windows clients are unable to connect to it at all.
When I look at the certificate they provided I see it is "Generated by RouterOS" suggesting to me they are in fact using a MikroTik router themselves.
The certificate they have provided is the CA certificate using which the server certificate has been signed. The fact that it has been generated using a Mikrotik does not necessarily mean that the server you are connecting to is a Mikrotik one itself.