As pointed out by Mat in the comments, unless you specifically set up auditing it is highly unlikely that the command as such is deliberately stored anywhere and kept in a directly accessible form.
grep -lR ... / as root might be an enlightening experience (you may want to remount everything
However, there is always a "but". In this case, one obvious possibility that I can see (especially as you don't securely clear the $password or $estring variables in the code you have shown) is that the contents of those might be written out to swap space. That would mean that they are committed to permanent storage at least for a while even not in the presence of an active attacker. This can be largely mitigated by either disabling swap entirely, or running swap encrypted with a random encryption key, which makes the swap inaccessible after a reboot (because the decryption key needed to make sense of it is lost when the system RAM is cleared).
I would imagine that 7zip is well-behaved enough to clear out the password from its command line quickly and then further from its internal variables as soon as it is no longer needed, but things like expanded key schedules might be kept for a longer period of time thus increasing the potential for them being swapped out. Those won't necessarily allow recovery of the password, but they may very well allow recovery of the plaintext from the encrypted archive. A simple
ps axw issued at just the right moment will show someone who is logged in the password in plain text from the command line, but it isn't stored and the window of opportunity is small.
When you send the e-mail, I presume that it contains the password in clear text form (or something that is easily derived into the corresponding plaintext, such as a Base64 encoded message body). That e-mail almost certainly will be temporarily written to the system's mail queue, which means that the password does end up on disk (unless you have the mail queue directory on a RAM disk, which besides the fact that the mail queue is supposed to be on persistent storage presents its own set of problems operationally). Especially if you are running a smarthost setup the queue file will likely be deleted very soon afterwards, but since it has been written to disk, "the damage is done" so to speak. Something like
strings /dev/sd? on any server the mail passes through will probably recover the password to anyone who knows what to look for unless you take specific steps to mitigate this threat.
Of course, e-mail in the first place isn't designed to be completely secure. The only way to have reasonable confidentiality assurances with e-mail over SMTP (even if you are using SMTP over SSL, or STARTTLS, throughout the entire chain of mail servers) is end-to-end encryption like S/MIME or OpenPGP.
TL;DR: Your web application probably doesn't deliberately store anywhere the command including the password, or the password itself, but other components it relies on very well might during the course of normal operations.