In my experience, a lot of code is like this, and the majority of startup code is like this. I have found there's almost zero correlation between startup success and good coding practices. I have no data, but I suspect there's a negative correlation.
Before you protest, I know that your code is a shining example of clarity. But if you consider all the incentives for a startup, there's much more value in being experimental, and highly responsive to customer demands, than there is in charting a stable, long term course. People celebrate pivots like it's cool, but this is what it does to the code.
Just a forewarning for anyone who is going from a more corporate world into startupland.
The idea here is that you do the best you can within the constraints, not that you use your start-uppishness as an excuse to be sloppy or to produce crap.
In fact, the majority of the real messes I see are not in start-ups but in more established companies where the original developers have long since moved on. Large codebases where very few people (if any!) have an idea of what is really going on.
I have been at startups where it's a total mess that will never be cleaned, and I've been at startups where the code is always tip-top because everyone knows you get big B2B points for implementing their dream feature right after a regular "how are you liking our service" followup.
I haven't worked at mega-corps, but I've seen bits of code that is so much worse than imaginable that I expect there are places that scrape pretty far below the bottom of the barrel, but that might just be a volume issue (the worst 1% of code will be mostly mega-corp code because most of _all_ code is in mega-corps).
If the founder made an in-depth reply explaining that "No, we don't suck, we use language X, framework Y and methodology Z", then that just opens up a pointless side discussion about whether the X+Y+Z stack sucks, and how much exactly.
All that will remain in search engines, so in a few years' time the company will appear in public searches as a company that uses X+Y+Z even if they have moved on.
Note that this wasn't a debate about languages, frameworks or methodologies. The OP flat out referred to the company's code as "tangled mess of mindless duplication, half-implemented features and misleading comments" and claimed that only one employee "knew anything about the system." The response here mentions surfing on Wednesday but doesn't dispute any of the OP's claims about the state of the company's technology and technology organization. That looks horrible.
As a company you want to shut this sort of discussion down as quickly as you can. A detailed rebuttal may appear to do that but doesn't - the more you say, the more you raise questions, invite rebuttals and encourage further debate.
Maybe this doesn't answer some claims and they suffer some very slight damage because of that, but far worse damage is often (possibly even usually) done by detailed replies which keep the story going and fuel the fire.
Why? A former employee criticizes the company they were fired from -- that carries essentially zero weight to pretty much anyone, and you seem to be among very, very few who took it at face value. Heck, even if they weren't fired and didn't have the axe to grind, people complain about "spaghetti" code with such vigor and frequency in this industry that it has become essentially meaningless: It's the standard fall-back when someone is in over their head -- attack others, malign their code and technology, and try to pull up yourself by tearing down others.
Further, how in the world can you complain about them commenting on a "personal" matter, when they are responding to a guy who posted a highly-critical extortion rant. I call it an extortion rant because he even claims that if he warned them that they need to pay up or face his public flailing.
That's incredibly lame.
He wouldn't be the first one.
I had a bunch of jobs, where I had to work with crappy code and have seen many people getting "terminated" because they prefered to complain about it.
I complained too, but I worked with what was given, when it didn't change after a few years (most of these "the whole system is fucked up changes don't come easy) I just quit.
These things are self evident to any programmer who isn't in their first year of work. I can't see anyone being fired over recognizing what their experience allows, especially since you hired them for that experience.
The OP basically called into question the quality and stability of Unbabel's platform ("The code was a tangled mess of mindless duplication, half-implemented features and misleading comments. Of the few automated tests that existed, most didn't even run anymore") and the competence of the people behind it ("The team lead was the only one who knew anything about the system and he was either busy trying to patch things up by himself or working with the other person they had hired for my position before I got there"). The subtle implication of the post: the OP may have been terminated because he recognized these things.
Are the OP's claims true? Who knows, but the response here doesn't directly address them at all. Instead, there's ambiguous language like "terrible fit", corporate-speak like "we believe that the culture of the company is extremely important" and a poorly-timed "A position just opened up :)"
Frankly, if I was the founder of a tech company and I made the decision to respond publicly to a situation like this, the claims about my platform and the competence of my team would be my focus and I'd address them head on. After all, such claims could become very harmful when encountered by prospective employees, customers and partners. Given that, it's curious they were completely ignored.