The confusion is mainly caused by the fact that PPTP isn't used today the way it was originally intended. The PPTP protocol wasn't created as a VPN protocol, the PPTP protocol was created to solve a common problem of that time: PPP multilink aggregation at ISPs.
At the time the protocol was created, most people would still connect to the Internet using modem connections over phone lines. The bandwidth of such a connection is rather limited and soon became a limiting factor. People tried to work around this by just getting more than one phone line and establishing multiple modem connections to the same ISP. This was working fine, as long as the ISP operated only as single dial-in concentrator at that all Internet traffic would terminate as well. However, if the ISP operated multiple of these, two connections could dial into different concentrators - it was random where they would terminate - and then aggregation wasn't possible any longer, since traffic from the Internet could only terminate at one of these concentrators and thus effectively only one modem line was really used. People would then hang up and dial in again and again, until they finally hit the same concentrator with all their lines. I guess everyone sees the problem here.
And this is the problem that PPTP should solve. The dial-in concentrator was split up into two components: The PACs and the PNS. The user dials in to any of the PACs and the PACs tunnel all traffic to a central PNS, which is where all Internet traffic terminates, too. Even when dialing in multiple times and to multiple PACs, the system would still work as desired since the Internet traffic only terminate at the central PNS and not at the individual PACs.
Source: https://www.decodednode.com/2014/03/vpn-terminology-pptp-and-l2tpipsec.html
Note that PPTP is only spoken between the PACs and the PNS; components left to the PACs and right to the PNS knew absolutely nothing about PPTP.
Later on PPTP was also used for VPN tunnel services provided by the phone operators. Therefor a PNS was placed into the private network of a company, while the PACs were still operated by the phone operators and telecommuters could dial in to the PACs at that phone operator, authenticate, and then get direct access to the private company network through the PNS located there. The phone operators would guarantee security and confidentiality of all traffic exchanged between PNS and PACs, however they did it, as PPTP itself provides nothing like that.
With the decease of modem connections, the protocol became pretty much obsolete, yet it has been widely adopted by many companies for VPN services, and with the PNS still in place, the protocol was recycled as a VPN tunnel protocol. Now the VPN client computer itself would pretend to be a PAC and connect to the PNS over Internet. To ensure that the data is still secure without phone operators providing security, Microsoft just extended the PPP protocol by adding encryption (MPPE) that works with keys derived by the MS-CHAP(v2) authentication protocol and now the tunnel data itself (wrapped in PPP over GRE) could be encrypted. As all of that happens in the PPP protocol, it was not required to touch a single line of PPTP code on any PPTP client/server for that (PPTP itself is still unaware of all that).
Note that for the PPTP management itself, the roles are not important. It plays no role who is the PAC and who is the PNS as either side is allowed to request a new connection from the other side, the roles are completely interchangeably. The roles are only fixed for the call management (outgoing and incoming phone call requests), yet the entire call management has become obsolete, as nobody is calling anyone anymore, it is only required to register a call ID as that ID is required when tunneling traffic over GRE.
Thus Microsoft has just swapped roles:
In this document, the terms PPTP Access Concentrator (PAC) and server, and the terms PPTP Network Server (PNS) and client are used interchangeably. This document specifies the use of voluntary tunneling where the PPTP tunnel endpoints and the PPP endpoints reside on PAC (as the server) and PNS (as the remote client).
Source: [MS-PTPT]: Point-to-Point Tunneling Protocol (PPTP) Profile
Now the PAC is acting as a server whereas the PNS is acting as the remote client. The PNS establishes a connection to the PAC (which is allowed by RFC) and then requests an outgoing call to register a call ID.
Funny enough, Microsoft itself is getting confused about this within their own document:
The following example shows the sequence of messages exchanged when a machine running Windows Vista operating system with Service Pack 1 (SP1) (name: "testclient.contoso.com") with IP address 1.1.1.1 (client 100 megabits per second connection) establishes a PPTP tunnel with a machine running Windows Server 2008 operating system (name: "testserver.contoso.com") with IP address 2.2.2.2 (server, 100 megabits per second connection).
In this example, the machine "testclient.contoso.com" is PAC and the machine "testserver.contoso.com" is PNS.
Source: PPTP Protocol Examples
The last sentence is wrong, it is supposed to be exactly the other way round according to introduction of that document.
I guess most modern implementations simply don't care, as they implement all parts of the protocol and thus can act as PAC or as PNS, even on a case to case basis. After establishing a PPTP control channel, neither side will know if it is supposed to be act as a PAC or as a PNS, so either side can send an outgoing call request to the other side, which would then set the roles as "the sender of that request is the PNS, the receiver is the PAC" but until such a message has been sent, the roles are open.
And considering the way the protocol is used today, it just makes more sense if the server is taking the role of the PAC. It surely also works the other way round but would seem illogical to most network developers, as the messaging would seem mixed up between client and server (the server would be sending requests to the client, the client would answer these requests and actively notify the server of status changes - most people expect the opposite).
Not really part of the question but obligatory to mention when talking about PPTP: Please note that PPTP is completely insecure as of today! MS-CHAP(v2) uses the weak DES algorithm for cipher operations, that can be cracked with brute force using custom cracking hardware. Also the derived key used for encrypting payload data, which can be 40 or 128 bit, is always used with the RC4 cipher and the NSA is known to be able to crack RC4 in real time. L2TP has been introduced to replace PPTP since it is much better designed, yet it is also overkill and the security of L2TP is only provided by IPSec, thus you would get the same security level by directly using IPSec as VPN tunnel protocol, just with much less protocol overhead (tunneling IP in IP is directly possible using just IPSec, no other protocols required). IPSec is still by far the best VPN protocol still in use, SSL based protocols (like OpenVPN) might be easier to setup and cause less trouble in restricted network environments but they cannot match IPSec in either security or speed. I would only use them as a fallback in situations where IPSec cannot be used.
