Is browser history an important factor when considering security?

Yes, this is a vulnerability. You can point them to such august bodies as

• OWASP Top 10

  • https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url
  • https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
• CWE
  • Information Exposure Through Query Strings in GET Request https://cwe.mitre.org/data/definitions/598.html
  • Insufficiently Protected Credentials https://cwe.mitre.org/data/definitions/522.html
• StackExchange
  • https://stackoverflow.com/questions/26671599/are-security-concerns-sending-a-password-using-a-get-request-over-https-valid

The common problem is that the credentials are stored on the client-side in the clear (browser history) and on the server side (webserver connection logs) and there are multiple methods to access that data.

Yes, it is laziness on their part. They are thinking of their code alone, and forgetting the client-side and the infrastructure.

Secrets do not belong into URLs. URLs appear in browser histories, in proxy caches, in server logs, get sent to analytic service providers and can appear in many other places where you don't want secret information to appear. Using HTTPS (they do use HTTPS, right?) only prevents proxy caching, none of the others.

Users might also copy & paste URLs around without noticing that their login credentials are still in them.

Therefore, registrations and logins should use the HTTPS POST method with the login credentials in the body of the message.

First rule of product security: Never, ever, trust the vendor saying that a security issue is irrelevant.

I won't duplicate the technical answers given already. I want to expand on them and point out that the assessment that leads them to evaluating the issue as irrelevant is based on assumptions which may or may not hold up in the customer environment. Without a solid understanding of your environment they cannot make this call. That's like a car company saying that driving their new model at 250 km/h is perfectly safe - it probably is on the test track, but on most real-world roads it wouldn't be (road quality and traffic).

This becomes clear once you understand just how flawed their evaluation is. Aside from browser history, a GET parameter will also show up in proxy logfiles and it can be mistakenly mailed when someone wants to share a link, to name just the two most obvious other ways in which this secret could leak thanks to their bad engineering decision.

Taken both the vulnerability itself and their bad reasoning and handling around it together, I would seriously doubt their ability to manufacture secure products. I would let them know in no uncertain terms and re-evaluate the product in light of this new information.