Since I spammed the comment section I might as well compile the comments here into an answer.
As David Carlisle and Peter Wilson commented, you have already done a very good job at outlining the two possible choice and their pros and cons.
The only difference between the two is really that with a class you can stop a user from using an incompatible (or their favourite - it depends on the view) document class.
Specifically for your company layout the best choice may well depend on how comprehensive, detailed and explicit your corporate identity policy is.
If you have a fairly comprehensive policy, I would definitely go for a class. Document classes are mainly chosen for their looks and the ability to customise the looks. If your company imposes a specific look, there is no point in your users wanting to deviate from that by using their favourite document class - you take over the full formatting anyway.
If, on the other hand, your company policy is less overreaching, goes more along the lines of
Use a 12pt sans serif font, write the name of the company in ALL CAPS, put our logo on the top right, the name of the CEO in the footer and leave a 2cm margin on the right
leaves a lot of wiggle room in some places and has nothing to say about other areas, the two choices might be more evenly matched. I would still go for a class in that case, though. A .sty
that can not be guaranteed to work is just about useless - you will either end up annoying users that things don't work as advertised even though you allowed them to keep their favourite document class and classicthesis
add-on package, or you will end up fixing your template for all those eventualities leaving you with a mess of class/style-dependent fixes. Of course you could write a .sty
that works together with the big three class families (standard classes, KOMA and memoir
), but that is at worst about three times as time consuming (take section headings for example, I believe each of the class families has their own preferred go-to solution, you'd end up writing three bits of code to do the same thing).
This discussion somewhat naively assumes that document classes are only chosen for their looks and the abilities to customise the looks. This is probably not entirely true since some document classes (the KOMA classes and memoir
come to mind) offer other nifty features as well.
If you write a document class or style maintenance is an important issue. You (or someone else) should be prepared to accept bug reports and feature request and make sure that the code conforms to best practices even as time goes by. Writing the thing once and then throwing it out there without support is asking for trouble.
You may also want to read https://github.com/johannesbottcher/templateConfusion. And if you read German maybe also https://komascript.de/latexvorlage.
.sty
since you want to take over the styling of the document. The fact that your users may like other document classes is largely irrelevant since they chose these document classes for their looks (or the ability to customise the looks) - and not for other functionalities (at least that is the idea). Since you take over the looks, there is no point in them insisting on their favourite class..cls
. A.sty
that can not be guaranteed to work is just about useless - you will either end up annoying users that things don't work as advertised...classicthesis
add-on package, or you will end up fixing your template for all those eventualities ending up in a mess of class/style-dependent fixes. Again, assuming the users should not interfere with the styling of the document there are very little commands of their fancy document class that they should want to insist on using in your document (though KOMA and memoir offer some really nifty features that can not be considered to be only about styling - so things are not as easy as I say).memoir
;-). The questioner ably put the case against using a package with an arbitrary class versus a specifically designed class, while you have expanded on the advantages of a company-specific class.