TL;DR: HTTPS provides encryption, and it's the only thing protecting the parameters.
It's well known that GET requests with ?xx=yy arguments embedded can be altered in transit, and therefore are insecure.
If you are not using encryption, everything is insecure: HTTP, Telnet, FTP, TFTP, IRC, SNMP, SMTP, IMAP, POP3, DNS, Gopher...
If I change the request to POST...
...it does not change anything at all.
and use HTTPS...
HTTPS changes everything.
Any HTTP request not protected by TLS is not protected. No matter if you use GET, POST, PUT, if it's a custom header, none changes a thing.
For example, this is a GET request:
GET /test?field1=value1&field2=value2 HTTP/1.1
And this is a POST request:
POST /test HTTP/1.1
What is the difference? On the GET request, the parameters are on the first line, and on the POST, the parameters are on the last line. Just that. The technical reasons behind GET or POST are not the point here.
Suppose GET style parameters were added to a POST request - would those parameters be reliably ignored?
It depends entirely on the application. On PHP, for example, if the application expects
$username = $_POST['username'], sending it as GET parameter changes nothing at all, as the application will get the POST parameter.
What about some sort of security downgrade attack? If the URL manipulator forces HTTPS transactions to fail, and then the client/server "helpfully" downgrade to HTTP, which would allow the unencrypted POST body to be manipulated.
Not easy for properly configured servers. If they use the HTTP Strict Transport Security header, it forces the client to only access the site using HTTPS, even if the user forces HTTP and port 80. The browser will helpfully upgrade to HTTPS, not the other way.
Even on servers that not use HSTS headers, if the first access is done via HTTPS, it's not trivial to downgrade to HTTP. The attacker must send a faked certificate, and the client must accept the faked certificate in order to an HTTPS connection be redirected to HTTP. But if the attacker succeeded on this, he will usually keep using HTTPS as the client already accepted his fake certificate anyway.