It’s funny that the OpsWorks resource types would be the ones you’re actually using here because by coincidence it was me in a previous life (my old employer) who originally implemented aws_opswork_stack and the various layer types.[1]
And so I can, at least, confirm that I did originally want custom_json to be custom_data which accepts any value and have the provider itself JSON-encode it, and so this is one of the things in the category of “providers written under those constraints” which could possibly get superseded by a non-string version in a future release of the provider, once the provider team is ready to adopt the new SDK.
Though I don’t work on the AWS provider anymore, so that’s of course not for me to commit to either way; I know there are various other examples that are probably more commonly used than OpsWorks. And indeed, by then perhaps you won’t need the OpsWorks resource types anymore anyway.
[1] I got a nice reminder of a funny bit of history here, where implementing this was when I first encountered the very limitation I was describing above, and at that time made a prooposal to address it. Although that particular proposal wasn’t accepted (for good reasons, in retrospect), we did finally get to address it in a different way as part of Terraform v0.12. 
Hopefully it won’t be long now for providers to start making fuller use of it.