Addinga custom permission will never "magically" make a feature work. No component is checking for a "CreateComments" permission, so adding it has no effect. The poster from the thread you linked also includes the abstract instruction: "After that you need to extend the comments webscripts in share so they do not use the Create permission, but CreateComments permission . I think it's the comments-list.js file, but I can't find my example code for this." This sounds like it was intended to work with the custom permission, but actually won't work at all as well, since it is just a UI component checking permissions, but regardless of its check results the backend will still fail due to lack of the right permissions.
What you'd need to do is apply some sort of customisation / logic that automatically adds the "Contributor" permission on the discussion node for a document to users with Consumer / Read privileges on the document. Unfortunately, that would be quite an inefficient approach. Alternatively, you could try to implement a DynamicAuthority - combined with a "globalPermission" role definition in a permission definition XML - that dynamically grants the relevant Contributor privilege on content / discussable items if the current user has read permissions. That avoids having to create many ACLs on each node individually, but requires Java implementation. Once that is done, you might still have to do some UI customisation to activate the comment action for Consumers, but then at least the action would be supported by the backend.