If you want to be a computer scientist, can competitive programming be helpful early on in your career?

All types of practice are valuable, and if competition pleases you, go for it. However, programming quickly and under pressure is more akin to industry than to academia, and may leave little time for theory. Therefore I'd not call competition "important" for formation in CS, rather it's one of a number of forms of structured programming practice.

Their are three things to my knowledge commonly referred to as competitive programming.

All are mildly beneficial, none are crucial, and winning never matters.

Code Golf and Programming Puzzles

This is the least useful perhaps. If it is being done in the langauge you work in (rather than in a golfing langauge) it can arguably keep you familar. Really though it is a form of mental exercise. Keeping your brain fit.

ACM International Collegiate Programming Contest etc

These tend to be restricted to undergrads or even highschoolers.

These involve becoming very familiar with a lot of algorithms. Eg Dijkstra's algorithm, bellman-ford's algorithm. And with important techniques like dynamic programming Becoming so very practiced at these algorithms and techniques can certainly help one recognize when they are applicable to a research problem encountered down the line. I know someone who became a very proficient at restructuring problems into things they could solve with dynamic programming during such competitions as an undergrad. They have spent their PhD not only using it to solve their problem in some genome sequencing related area, but then meeting other biological researchers (without the strong algorithm design background), and being able to solve the problems they have been fighting with for months in days -- which is a rad way to get a pile of collaborative works.

One word of warning is to not let them blind you. They use a restricted set of tools -- often just a few programming languages with their core library -- and the problem needs to be solve entirely in them to the end. But outside of those rules, there are more options that may be not notices. E.g. if you can transform your problem into a mixed integer programming problem, you are probably done. It probably can't be made into a simpler problem (that is not NP-Hard), because that tends to be fairly obvious ^{(citation needed)}. And once it is in that state you don't need to write a solver for it, you can just use one "off-the-shelf".

Hackathons

These have nothing to do with coding. Hackathons are about building contacts. Yes, you write code, but you are probably not writing code that is academically interesting. (the coding may or may not be interesting to regular programmers, but regular programmers are not what this SE is for)

But they are a good place to meet people. Sometimes the tools wanted to be made are for researchers in non-computing areas, and they need soemthing to gather-data, or something that lets them "productize" their research.

Sometimes that lets you put your face out their for industry people, who know know X is doing a PhD on topic Y. Then 6 months later: "Wow we really need this problem related to Y solved. We should get in touch with X". And then maybe you get to do some research on their dime.

However some hackathons are exploitative, eg requiring you to pay to prototype something for a commercial company. Rules for hackathons:

• Never pay to attend. One does not pay to work.
• If they do not have mentors/clients/competing teams who are going to make good contacts done attend.
• Don't do 24 hour or 48 hours of continuous work. It is unhealthy.

Their are enough hackathons around that you can be picky.

I'd say it's a fallacy of converse logic. The winner of a hackthon is surely a good programmer, but the converse is not necessarily true that all the best programmers are good at hackthons and competitions.