tl;dr don't trust HTTPS alone use it as one part of layered security and do use SRP always. bcrypt the password as input to SRP for additional protection. AES encrypt the verifier in the database for additional protection of the offsite backups.
Hashing the password with bcrypt on the client only makes it harder to recover the password if the server's database is captured. It does not protect against interception. You should not assume that you will have good SSL/TLS in the form of HTTPS to your clients for reasons which I will outline in detail below. With SRP you get more benefits as described in this excellent answer by @poncho:
The security goal behind SRP is that an attacker that could either
pretend to be a client (and attempt to log into a server that knows
the key), pretend to be a server (and allow clients that know the key
to attempt to log in), or actively monitor (and modify) the
communications between a valid client and a valid server would learn
nothing from an exchange, except possibly whether a single password is
valid or not.
With SRP there can be no replay attack as each login attempt has to perform a password proof for a fresh server-generated random challenge. Using bcrypt alone someone can intercept what the client sends to the server and they can login as the client until the client changes their password. With SRP an intercept is useless. bcrypt of the password as input to SRP slows down a dictionary attack if the verifier is stolen. Encrypting the verifier with AES in the database reduces the risk of the verifier being leaked.
As @Thomas points out if you have SSL/TLS such as HTTPS then , in theory, you know that you are talking to the correct server, with no man-in-the-middle, so you are safe. This theory is demonstrably unsound in practice due to the operational complexities inherent in maintaining a secure HTTPS site correctly and due to commercial man-in-the-middle software routinely deployed by large corporations.
The Heartbleed bug leaking unencrypted text from the server had existed for long enough that an estimated 17% of HTTPS sites were vulnerable. Once it was a known attack people demonstrated it against famous sites damaging the reputations of those sites. Those sites could have been secure had they used SRP over HTTPS.
Many large corporate websites only use HTTPS into the public facing DMZ and then use plain text from the web servers through to application servers, then the plain text from the application servers to the database servers. This potentially risks plain text passwords being leaked in log files, or being recovered by malicious employees or contractors maintaining the infrastructure. SRP protects against this.
Large enterprises such as global financial services firms routinely run main-in-the-middle scanners between their employees and external HTTPS sites. There is commercial software for this which is not widely advertised. (I know someone who was a consultant for HP installing such software for large corporates for two years). This relies on the fact that employees use a browser which accepts a certificate from the corporate web proxy which decrypts, scans, then re-encrypts, and forwards to the external sites. (Edit: Actually a colleague just told me that IE can be configured to offload encryption to the local web proxy although I have not confirmed this personally.) This 'attack' is done to prevent rogue employees from stealing client data or corporate intellectual property. (Or to prevent employees tunneling file sharing protocols over HTTPS). See https://security.stackexchange.com/q/63304/45960 for one example. Such software may leak passwords into log files or have a bug which compromises passwords or be maintained by malicious employees or contractors who might attempt to recover passwords.
Finally, I have personally seen a mistake in upgrading an online banking website where a misconfiguration between the versions of software deployed led to behavior identical to heartbleed. The application server software was upgraded but the web server plugin was not correctly updated to the matching version by the deployment script. The website ran fine yet pen testers throwing scripted attacks at the site got back plain text chunks of memory. They captured the customer support managers password whilst she was doing testing of the upgraded in a test environment (accessible via IP whitelist only) the week before the release was to due to go live. We rapidly fixed it then added two-factor authentication to the site at considerable cost. Had we known about SRP and had used that we would have been less vulnerable had the pen testers not found the problem before the software upgrade went live.
P.S. Even if you use two-factor authentication you should still use SRP for the password to guard against a social engineering attack where someone gets the password then rings customer support and impersonates the customer saying that they have lost their token and is given a one-time override.