So, you'll have to forgive any ignorances I have of techniques in the bitcoin world that aren't represented in that article. I'd love to hear rebuttals and specific inaccuracies. I tend to focus on my own work and lightly follow the progress in the competitive landscape and it's easier for me if you just tell me directly where I'm dumb :)
I believe stellar has many advantages over bitcoin in the non-financial domains: Simplicity, composability, latency, and expressiveness. Let's take a look at each in turn.
Simplicity: I feel this is the biggest advantage stellar has. I've now been working for several years to teach other developers to integrate cryptocurrency into their own applications. It's tough for most, and that isn't even considering hacks (in my opinion) like using the method you linked to using OP_RETURN. A developer using stellar, by contrast can actually experiment with setting kv pairs onto an account without even installing any local software. Check out https://www.stellar.org/laboratory/, you can roll a test account, craft and post transactions and re-read the stored data in,IMO, a really well implemented GUI. Sorry, I don't mean to brag about my own org... @_irisli did almost all the design and work, and she did a fantastic job in my opinion.
You may be familiar with the UTXO-based vs. Account-based models when it comes to blockchains. IMO, the account based model is much easier to work with and understand for developers. IMO, This makes it easier to layer systems on top of the underlying financial and consensus networks.
Our methods for publicly recording data into the blockchain is explicit. The operations you craft to perform the action were specifically designed for this purpose. I bet teaching someone to use our data operations is easier than teaching someone the OP_RETURN method, even just considering the number of code dependencies that are required to work with the latter.
Composability: Most hacks don't compose well because they often take more cognitive capacity to reason about. In short, they're complicated and their interfaces are not always easy to remember or operate correctly. At some point during software's growth, you end up with too much complication in the composition and have to refactor or rewrite. Explicit features and abstractions make that process easier, IMO. In short, bitcoin has more cruft, IMO.
Latency: SCP beats Proof-of-work on latency and efficiency hands down. There are alternatives for sure, but as far as bitcoin goes, it's not even in the same realm. This is important for systems built on top of a blockchain because it governs the tick latency of any two-way interaction. In short, you can build larger and hopefully more useful interactive protocols with stellar.
Expressiveness: The method you linked to describes how to write a message indelibly to the bitcoin blockchain and how to retrieve it given the transaction id. Not even counting hack-like methods, our system allows you to assign values to any number of symbolic identifiers associated with your account, and the storage at those identifiers are mutable and strongly consistent. You could for example, have an application that stores an encrypted backup in ipfs, then posts that hash into the "latest-backup" key on your account. Another example: This mutable, strongly consistent kv store when combined with a content-addressable storage network like ipfs would allow for what is essentially an internet-wide decentralized clojure ref (http://clojure.org/reference/refs).
Also consider trustlines (https://www.stellar.org/developers/guides/concepts/assets.html#trustlines) These look an awful lot like edges in a graph if you squint a bit. We're starting to get into hack territory, but IMO it would be feasible to build a useful decentralized graph database of some sort using accounts as nodes, data values as node attributes and trustlines as edges. Anyways, I'm going off into lala-land, so I'll end there.
Do the points above make sense?