They were trying to hire (and poach) just about anyone they could around this time. Therefore, these articles are... very shiny, compared to the actual tech applied internally (note that even though Uber is referred to in the third person here, this is on uber.com and written by an Uber employee).
I worked at Uber for a year. Schemaless was... meh. Nobody really liked using it, nobody really understood it, and you weren't really allowed to host your own instance - you had to have another internal team do it for you, which didn't help the "understanding" problem.
It smelled distinctly of "not invented here" syndrome. A number of things inside Uber worked that way - the culture was so competitive and brutal, performance reviews were always a massacre, so everyone was trying to outshine their peers (or outright climb on their backs, etc).
This resulted in a LOT of "tech" being "invented" that 1:1 did something already prominent in open-source or was already an enterprise solution (probably cheaper than paying engineers to do it) but since actually achieving it and having your name on it meant you would look better for a promotion or a bonus or whatever over a colleague meant it was worth it to the individual to reinvent the wheel. Rinse and repeat over and over again.
I'm not an enemy of reinventing the wheel, mind you. But only if the new wheel works significantly better than the old one. This was rarely the case at Uber.
Postgres was still used somewhat commonly at Uber when I was there, but they were really pushing for Schemaless internally. It felt very overkill for just about everything outside the platform teams and was always, without fail, a massive pain to deal with.
Don't be fooled by these Uber engineering articles. This was PR to bolster up their OSS image to outsiders to help with hiring and poaching at the time. Things internally looked very different.