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.