Relatively free form key value pairs except some other stuff that matters for your domain works just fine in a relational db, you just have to query for it when you need it. If you already have a db and an ORM, which would be the common case in any enterprise environment, you'll get your getters and setters for free once you specify class/member->table/column and you can have an attribute table in the without breaking step. How this would be hard to set up or use compared to a key/value store is a mystery to me.
I've worked on a couple apps that were admin configurable via extended properties and did exactly this against a relational db at runtime. It works fine. Actually, better than fine. Let's say in the future you want to use them in aggregates or use them to filter rows on large datasets. Keeping everything in a relational db, dealing with that need after the fact is easy, and efficient if you choose to make it so. Split your stores and not so much.
YMMV always, but I think your vendor just sucks if your keys and indexes aren't encrypted along with the data. Anyways, if you want to encrypt/decrypt in the application you can, the nosql folks who haven't gotten around to supporting that (or COMPRESSION in some cases, really) like that argument.
But hey, let's say you want really, really unstructured data without any mapping into your model? Fine, use a lob, and pardon me while wretch. Point is the tool doesn't actually have any simple functional shortcomings compared to a key/value or simple document store, it's just that it gives you the option to impose a little more discipline, and from painful experience most people have chosen that option.
I'm not saying these things don't have a place, but it's more limited than acknowledged, and purported advantage of being schema-less is pretty stupid. The only related argument I've heard that has any sense to it is about uptime, but ultimately that fails for me, too. First 99% of schema changes are simple additive ones that have no impact on uptime. Second even the 1% can be handled pretty well in most cases restricting writes on a limited basis. Lastly, if this update outage is really putting you in knots you can keep modification dates (or just add them for this use case) do the 99.99% of the data transfer ahead of time then the write outage window can be TINY because the final set of data to transfer is so small.