Is a redirect showing the password in plain text a security vulnerability?
Definitely problematic - and worth reporting.
If the HTTPS is properly protected with HSTS and preloading, then threat actors observing the traffic wouldn't be able to see the GET contents. But since HSTS is still somewhat rare (and if they're putting plaintext passwords in a GET, they're probably not aware of other best practices like HSTS), the interception/downgrade risk is probably somewhat high.
Separate from that, regardless of the health of the HTTPS setup, remote HTTP servers almost always log full GET contents in the server's logs - so those plaintext passwords are probably being recorded on the server as well.
[Edit: and vakus' answer covers the rest of the attack vectors much more thoroughly!]
This should be reported right away.
There is a multitude of possible attacks which could result in compromise of user accounts.
The password shown as a GET parameter is not only a vulnerability according to OWASP, there are many ways those could be abused.
Common vulnerabilities allow the theft of protected passwords through attack vectors such as SQL Injection. Protected passwords can also be stolen from artifacts such as logs, dumps, and backups.
(Quote and link from March Ho's comment)
I would go even as far into considering finding another service, as such policy shows a lack of competence.
Here are some highlights that can be included in the report
Log file
The password submitted by GET parameter will be logged into a log file. This means that an administrator of the service is now able to view your passwords in plain text. This is as bad as storing passwords in plain text in the database. There is nothing which assures users that the administrator or privileged person won't turn rogue and use users' passwords to access their other services. And as we all know password reuse is more than common.
This also means that if the system is compromised the attacker only needs to read the log files rather than crack the database. This is a huge vulnerability and would result in many user accounts being compromised across many platforms.
A similar thing happened to twitter recently, where passwords were stored as plain text in one of the internal log files. Twitter have prompted all users to change their passwords, including on other websites where the users used the same password, even through there was no evidence of compromise or abuse of this bug. This shows that this may have serious impact on the users if the server would get compromised.
Shoulder eye picking
Anyone who is nearby would be able to see your password in plain text and could note it down. That password could then be used to compromise other services, because passwords are often reused across services.
Browser history
The passwords would be stored as a part of web browser history, meaning anyone with access to your computer and web browser will be able to log into your account without knowledge of password. This only gets worse if you are using a public computer.
As a result of this anyone with access to the history can now also copy your password and login, again allowing to compromise your other services.
HTTPS
You said that the website operates with use of HTTPS. There is however no guarantee that the website is using preloading and HSTS.
HSTS will force a web browser to load the website over an HTTPS connection.
If the website is not using HSTS, then the website may fail to be upgraded to HTTPS connection. This can be done via SSL Strip, which will turn all HTTPS links to HTTP. If the website is using HSTS, the web browser will automatically try to load the website over HTTPS, and if not able to will refuse to connect by HTTP. However even if the website uses HSTS, if the website was never opened before on the target web browser, SSL Strip attack would till work, as the web browser would not yet know that this website should only be loaded over HTTPS.
To prevent this an website would use preloading. For preloading, the web browser would have a built-in database of websites which must be loaded via HTTPS and should never be loaded by HTTP. This effectively would prevent an HTTPS downgrade attack.
Security audits
The fact that the passwords are stored as part of the log file shows that the company is most likely not performing security audits, or if they are, that they are not very heavily focused on security as a company.
HTTP Referer
As mentioned in comments by Mr Llama
GET parameters can appear in HTTP referrer headers as well. Any off-site resources loaded from the page may also be shipped your credentials via referrer header.
Link Sharing
If for some reason you need to give a link to the website to someone else e.g. coworker, you are more than likely just to copy it and send it to that person. This would again give this person access to your account and your login and password information, which can be used to access accounts on other platforms.
Search Spiders
Search spiders are basically following each possible link on a website and indexing it. While this is less probable, a search spider like Google or Bing could index an exposed link and show it as part of website search. This would mean that people could log into your account from Google or Bing.
I would go as far into reaching out to the company as urgently as possible. The security impact of this is huge and will affect many users.
I would even consider changing the SaaS provider if possible, and if the company would not comply to the report, they should be publicly shamed for plain password offending.