You need to do more accurate calculation for an amount of the purposes. For end users, your utility has single purpose, right, but for it's code this isn't so.
Let's see, there's the part you denoted
DoIt - it has that single purpose of doing utility function, fine, but besides it there's a part you called
Main and it has own, separate purpose - it serves as program entry point.
You see, code serves at least two purposes, not one (second one isn't visible to end users but maintainers of your code will see it very well). And, if you happen to also have command line arguments passed to utility, there will also be a code with third purpose of parsing these, go figure.
All right, there is more than one purpose, and serving them in one class deviates from a single responsibility principle (SRP) - from this perspective you have full right to split it, you only need to decide whether deviation is justified or not.
Say, if your code to handle command line arguments is only 5-10 lines, benefits of keeping it nearby most likely outweight blind adherence to theoretical principles. Or maybe your
DoIt code is so clean, elegant and compact that having even a small amount of unrelated parsing code there makes you feel "dirty"? if so, don't hold your pain, split it out and feel better - the very purpose of SRP is to justify moves like that.
Similar reasoning applies when you decide whether to keep the entry point in or split it out. If all your code is in single file, it's only reasonable to assume that anyone reading it will figure that entry point is also there. If you have more than that, well, it makes sense to give it a little more thought.
I for one feel quite frustrated when entering an unfamiliar codebase I have to waste time trying to figure whether to start reading code from
MyVeryImportantClass or from
MyAbsolutelyNecessaryClass. In cases like that, I would much appreciate if there was a simple, separate (however small)
MainClass file I could start with without thinking.