Is asymmetric encryption ever recommended for long-term storage?

Yes, this is a good scheme for medium term storage, as long as it's implemented properly.

A few things to keep in mind:

• Common asymmetric algorithms use semiprime factoring as their basis. As such, you can only encrypt data as long as the key, e.g. 4096 bits. This isn't very practical, so normally you would encrypt a symmetric key with your private (or, in this case, public) key and encrypt the data using a symmetric algorithm. So you'd use AES to encrypt the data, and RSA to encrypt the AES key.
• Asymmetric key lengths have had to grow at a much faster rate than symmetric keys. It's generally considered that RSA 1024-bit is secure for now, but 2048-bit is more appropriate for anything you're going to need to remain secure for more than a couple of years. If you're looking at storing data for longer than 5 years or so, you're going to need 4096-bit or 8192-bit keys. That's not exactly performance-friendly, but it's a requirement. In contrast, with symmetric encryption, it's thought that a 256-bit key couldn't ever be cracked with conventional methods, even with every ounce of energy on the planet, before the heat death of the universe.
• Quantum computers, whilst a long way off, might allow for semiprimes to be factored into their constituent primes in polynomial time, which would break such asymmetric schemes. If you're planning on storing the data for more than 20 years, keep this in consideration.

An alternative would be to have the client encrypt the data with AES-256, then upload it. They can keep their symmetric key on their machine, or derive it from a password using PBKDF2 or bcrypt.

You have basically described how encrypted emails work, with either S/MIME or OpenPGP. With emails, the data transfer and storage servers cannot access the email contents; in your description, you are just using Web-based protocols (i.e. HTTP) for the particulars, instead of the email transfer protocols (SMTP, IMAP...).

The details of encryption (which algorithms to use, how to glue them together...) are known to be hard to get right, so you should stick to studied standards for that (i.e. OpenPGP or CMS -- CMS is the format which is at the core of S/MIME).

Note that this is called "asymmetric" for a reason: asymmetric cryptography makes sense only if the people who encrypt are distinct from those who decrypt the data. If the same user pushes the data for storage and then later on retrieves and decrypts it, then symmetric cryptography is sufficient, and easier to manage.

It's a very good scheme in many ways, most of all that a server compromise cannot expose the data. There is one huge problem with it that is unavoidable, and that is availability. You aren't accounting for the human factor. You are expecting over years, perhaps decades, that people will be able to keep their private keys safe and available, and that's simply not going to happen!

The scenario is this: Bob creates an public/private key pair which he uses to encrypt the data on the server. 5 years later Bob gets massively drunk and leaves his laptop in the gutter he passed out in. Bob later realizes that he didn't include the directory where his key pair was stored in his automatic backup utility. Data lost forever with no hope of recovery.

I'd use client-side symmetric encryption instead, that way a server compromise cannot expose the data and it's up to the customer to store their password securely. Of course they could still lose the password, but it's easier to keep a password long-term than a private key. Better still you could offer an extra service that would store their passwords for them long-term, make some extra cash.