I wouldn't write code like the above because it's really mess, but it should get the job done. Is it a bad idea to implement such types of methods if your code is only going to be used by your own team, and not released to public?

To me, it's yes and no.
I would say NO if you write that code, then never back on it again.
But it's OK and Yes if you,
1, Are under heavy time pressure and want to finish your job quickly,
2, You are sure you will create a technical debt for yourself.
3, You are sure you will come back to solve that debt when you have time.
Then your code won't be that dirty because it won't exist permanently.

dirty local code that is encapsulated is okay-ish for quickly getting something to work. but fix it afterwards.

dirty global code (globals, singletons, too-big-to-fail classes) should be avoided at all cost. especially, as they typically never help in getting something done quickly, anyways. but cleaning them up afterwards can be hell.

The big problem with hacks like this, and the reason why they tend to become permanent "features" of a codebase, is that they can cause subtle side-effects that may then subsequently come to be relied on for other required behaviour. So instead of sitting down to write the code properly you decide that it's OK because it works anyway, but you risk missing the point that it's not working by design; it's working by accident.

When the time does come to clean it up, or to add new features to it, you may have accumulated a large amount of other things in the project that have a reliance on the initial misfeature, meaning that you can't do so without risk of breaking these other essential features.

However, I'm not even going to pretend that this is a prescriptive answer. Sometimes you do have to do things like this. It sucks, you'll feel dirty, but it's the only way. But do make sure that it's a last-resort option, do make sure that you've exhausted all other possibilities, and do make sure that you've read the relevant documentation/consulted the relevant authorities before brute-forcing it.

Most of the ToDos and FixMe:s in code seem to be there because the original programmer knew of a better way, but for some reason didn't do it, so the comment was placed there to ease his own "guilt".

I think the reason is usually time constraints, quite often a feature is needed yesterday (Either for a customer or for the rest of the team), quick solutions gets added, a comment written and as long as it works and doesn't cause any problems it will remain.

I think the important thing here is to not just add a comment to the code but to use a format for those comments that your documentation tools can parse, (That way you can get a good overview of all the quick hacks that exist in your codebase and the potential negative effects they have. (and if you don't use documentation tools it is a good idea to write a separate index for the things that should be fixed if there is ever time for it).

Personally what i want to know, just by looking at the documentation is:
The location of the hack, (File, namespace, class, function, etc)
The reason for the "hack" being used. (Time constraints ? , easier to reason about ?)
The potential drawbacks of the hack, (poor performance ? , bad scaling ? security concerns ? portability ? tight coupling ?)
Estimated importance of replacing the hack with a better solution. (I probably won't have time to fix them all, if i do have time i'd like to know where to start) and if possible a list of the better solutions that weren't used due to the reasons listed above.