A block cipher is a very versatile building blocks for implementing various cryptographic algorithms, such as hash functions, message authentication codes, and yes, also stream ciphers. You almost never use a block cipher on its own, but as part of some higher level construction. In a way, a block cipher is a bit like the engine in a car — it needs the rest of the car (or truck or boat or airplane) around it to actually do anything useful.
A stream cipher, on the other hand, does just one thing: it encrypts a stream of data. (Some modern ones may also authenticate the data being encrypted, to protect it from tampering.) While you can build a stream cipher by using a block cipher in an appropriate way, a purpose-built stream cipher has "no user-serviceable parts inside" — it's a bit as if a car had the engine and the frame permanently fused together, so that you couldn't separate them without tearing the whole car to pieces.
Now, the article does have a point is saying that the main source of vulnerabilities in block cipher based encryption schemes is not the block cipher itself, but the way it is used. To stretch the car analogy even further, cars don't usually fail because the engine blows up — more likely they fail because there's something wrong with the drivetrain or the steering or the electrics or the suspension, or because the driver was distracted and ran into an obstacle.
Also, because there are so many different ways to use a block cipher for different purposes, it's arguably easy for a non-cryptographer to select the wrong way of using it. In particular, to anyone who knows a bit of cryptography, saying that something is "encrypted using AES" is an immediate red flag, because it doesn't say anything about how AES is being used.
For all we know, you could be using AES-ECB (bad idea) or AES-CTR with a fixed nonce (really bad idea) or AES-CBC with a predictable IV (bad idea if the attacker can submit chosen plaintexts to be encrypted) or with padding oracle vulnerabilities (hard to avoid with CBC, and a bad idea unless you use a message authentication layer on top). Or you could be using AES-SIV (an excellent choice for a maximally foolproof design) or AES-GCM (a pretty good choice for raw speed, and secure as long as your nonces are unique) or even AES-GCM-SIV (a fairly new mode that combines the speed of GCM with the foolproofness of SIV).
Besides, the fact that you're using AES really isn't that relevant for cryptographic security — block ciphers are, by design, interchangeable, and any other unbroken block cipher with comparable block and key sizes is basically a valid drop-in replacement for AES. What really matters is whether you're using the block cipher in a manner that's appropriate for the purpose (e.g. any IND-CCA2 secure authenticated encryption mode for ordinary message encryption, an appropriate disk encryption mode for mutable random access data, etc.)
All that said, simply using a stream cipher doesn't magically make your code secure, either. Sure, with fewer choices, there are fewer ways to make wrong choices — but "fewer" doesn't mean "none at all", and worse, one of the possible wrong choices you can make with stream ciphers is choosing the wrong stream cipher in the first place, or not realizing that you may need something more than just the stream cipher.
In particular, most traditional stream ciphers (including e.g. DJB's Salsa20 and ChaCha ciphers, if used without a MAC) are vulnerable by design to exactly the same bit-flipping and nonce reuse attacks as block ciphers in CTR or OFB mode are. To protect against those attacks, you need an authentication layer on top of the cipher, and a secure way of generating unique nonce values.
So I would say that the conclusion ("block ciphers are now discouraged") is wrong. Block ciphers are here to stay, and there's no way that stream ciphers could ever displace them, because there are lots of things block ciphers can be used for that stream ciphers cannot.
What is (or at least should be) discouraged, however, is handing out isolated low-level components like AES or Salsa20 to developers, and expecting them to build a secure cryptosystem on top of them. What you should do instead, as far as possible, is use a standardized authenticated encryption scheme that already contains all the necessary components, and specifies how they should fit together, and which has been published and independently reviewed by multiple crypto experts. Preferably you should also be using a pre-existing implementation of the complete system that has been written by a competent cryptographer and published and reviewed for possible implementation flaws and side channel leaks.
Whether the chosen system is based on just a block cipher (like AES-SIV) or on a block cipher and a separate MAC (like AES-GCM or Poly1305-AES) or on a stream cipher and a MAC (like Salsa20-Poly1305) is, at that point, of much lesser importance. In fact, I would argue that it is completely irrelevant, except insofar as it affects the speed, resource use and external security constraints (e.g. whether the system needs a secure source of randomness, and whether it is safe to use on hardware that might be tampered with by an attacker) of the chosen system.
Ps. As for the recent popularization of stream cipher based encryption schemes, I would argue that it's as much a fashion swing as anything else.
At the moment, after a relatively long period where most crypto research focused on block ciphers, we just happen to have a bunch of novel stream cipher designs that are new and sexy (there haven't really been any prominent new block ciphers since AES established its position). Several of these ciphers, like Salsa20 and ChaCha, have been designed and promoted by a well known and trusted crypto researcher (D.J. Bernstein) who also happens to be the author of a popular crypto library (NaCl) and notably skilled at writing fast and secure low level crypto code, which also just happens to mean that they come with standard implementations that run blazingly fast on popular CPUs (which is attractive to companies like Google that transmit a lot of encrypted data over HTTPS).
This also coincided with the discovery of generic attacks against several widely used block cipher based cipher suites in the SSL/TLS protocol, which made it important to find new alternatives for them. As such, it's hardly a surprise that stream cipher based encryption schemes just happen to be in vogue right now.
