As for statements equating MQTT with CoAP style REST and why they're not complete or true:
CoAP URI path == MQTT topic
This appears to be true because they have a lot in common. In reality an MQTT topic is ephemeral (or you could say it's just a convention). You don't create it, you don't delete it, you just use it to synchronize where you're publishing and where you're subscribing.
A CoAP URI is material. Or at least it is with Californium, and I believe it has to be this way as long as CoAP is used in conjunction with CoRE link formats because all resources have to be enumerated so they can be described by the CoRE document.
This becomes very apparent when subscribing to a "topic" via CoAP. To subscribe, you send a GET with an Observe option set. But you have to send it to a "resource" so that you can be notified when the resource changes. With Californium you can't differentiate /messages?topic=foo/bar from /messages?topic=#. So when I implemented the bridge for 2lemetry I had to do it in 2 requests, POST /messages/subscription?topic=foo/bar and GET /messages/foo/bar.
MQTT payload == CoAP resource
Again, no. The CoAP resource identifier /messages/foo/bar attempts to represent a stream of MQTT payloads, but in reality only represents the last message. The trouble here is they're conceptually different which cause incongruities later. For instance, how do you ensure that you don't miss a message? After all, the URI only represents the last message sent. What if there's no messages sent to that topic yet? It's not straightforward.
The truth is that you can often change your architecture so that either MQTT or CoAP will work. But using MQTT as REST and using CoAP for publish/subscribe are both bad ideas. Know the tradeoffs.
Statement 1 is really about how MQTT wildcards don't have a parallel in CoAP. You're quite right this is an area of real difference. It's worth saying that it's also different between most other pubsub protocols too, eg. MQTT vs. AMQP vs. STOMP vs. XMPP.
In Statement 2 you talk about resources vs. streams. As Michael Koster pointed out, by having some conventions for mapping resources to payloads you can consider an observed resource to be a stream.
Your conclusion is false. MQTT was designed for streaming and pubsub, but it can be coerced into REST like behaviour with "state of the nation" topics. CoAP is designed for both REST and observation.
The two protocols are very different and each have their uses. But, saying that CoAP is not suitable for streaming and subscription based apps is simply false.