Create a Service for accessing Module class content

I believe the recommended approach is to copy the Info and InfoProvider classes of the module into a custom assembly that will also contain any additional code for the module and making that assembly available in the MVC app as well as the CMS app (dlls in both bin folders)

That is correct and (I hope) implied above. The "Business" project referenced is the custom assembly in Kentico 12 MVC training. I have added the classes there under /Generated/Modules/DoctorAppointments and made the assembly discoverable in AssemblyInfo.cs.

I am focusing more on the suggested pattern for working with Info and InfoProvider within the custom assembly through to the MVC website. Kentico has provided this for Page Types in their MVC training, but have not yet covered Module classes. This would also be implemented within the custom assembly, project "Business".

Treat them similar to how you would a page type. With the exception of a page type being a generic treenode object with additional bound fields from the other table.

Your module class is simply an object of type X. Module classes are very simple to work with, much more simple than page types. Unfortunately if you don't provide any bindings between objects they can be too simple and have no relationship to any other object.

My guess is you're o overthinking this too much and trying to over-engineer it.

Treat them similar to how you would a page type.

My guess is you're overthinking this too much and trying to over-engineer it

That's what the MVC training shows when it has you create Repository, Service, and DTO classes along with using the IoC pattern for providing custom Page Type content to Controllers through dependency injection. If I were to do the same thing for modules it would require the same "over-engineering", hence my question, "Is it worth it?".

Kentico is suggesting in their training material the following:

One of the main goals of the Business project is to hide as much of Kentico API calls from the MedioClinic project as possible.

It would seem that the answer for now is, no. Perhaps Modules should be an exception to this, where we should not bother with any additional layers of abstraction. Additionally, given how modules can have relationships (bindings) with other objects, it would be excessive to have to remodel that in the Business project. It also looks like Kentico doesn't have very useful generic providers for dealing with Modules like that have for Documents. I've found some DevNet questions that discuss this topic, but there is only very basic documentation it.

To answer your question "is it worth it?" If you have a relatively simple marketing site even with 100 pages, I'd say no. If you have plans to extend your site to do more than a relatively marketing site, then the answer is YES, it's always worth it.

You can generate Info and InfoProvider classes for your module classes just like you can for page types and custom tables. So getting access to those objects is pretty simple within your MVC project.