TL;DR: If your users are using 587 to submit email for relay, you need to secure it (by requiring STARTTLS before AUTH) or disable it in favor of an alternative like 465 (SMTPS). If none of your users is using 587, of course, you can disable it without concern, as all normal mail flows through port 25.
There are three commonly used ports for SMTP email - 25, 465, and 587.
25 is the standard SMTP port which is used by mail transfer agents everywhere. If that goes away, you will stop getting email from the rest of the world.
465 ("SMTPS" or "SSMTP", where the extra "S" stands for "Security") and 587 ("submission") are alternate ports which speak SMTP, designed for use by a more limited pool of your own trusted users. To quote RFC 4409:
This separation of function offers a number of benefits, including
the ability to apply specific security or policy requirements.
So, historically, these ports were use for things like allowing Mail User Agents to submit mail for relay, where the main SMTP port does not provide relay services. (In fact, 465 and 587 were introduced as a way of restoring functionality once "open relay" was closed off on port 25, which was itself a security measure.) Some other form of control (network ACLs or SMTP AUTH) are usually used with 465/587 to ensure only legitimate submissions are accepted for relay.
465 (SMTPS) is, like HTTPS, wrapped in SSL/TLS at the network layer. 587 does not require encryption per the RFC, but in common practice, nowadays many configurations will require STARTTLS (spinning up SSL/TLS during the SMTP transaction) before SMTP AUTH is even advertised. That specifically addresses the concern that your PCI scan is raising.
If your 587 (submission) port is like that, you may apply for an exception to the PCI scan. You can prove this by telnetting to port 587 and entering the command "EHLO hostname". If the response you get, like this one, includes STARTTLS but not AUTH, then you are not vulnerable to what the PCI scan thought you were:
250-submission.server Hello hostname [192.168.3.4], pleased to meet you
If it does offer AUTH while unencrypted, you will need to either require STARTTLS before AUTH or disable 587 and use something like 465 over SSL/TLS instead.
If you don't have Mail User Agents which belong to your domain submitting mail over the network for relay, you don't need 587 or 465 in any case.