I would claim cons for their choice were very lengthy build times and very spotty tooling support (most devs didn’t have any IDE functionality and things like linting were done by hand). Probably the main reason is just that they had sooo much code that the LSP couldn’t handle features like definition jumping and type sanity checks. As for the linting, that was a devops oversight: it would have been an easy get that they never prioritized. Some of these tooling issues may also be resolved by more recent renditions of the LSP. Surprisingly, PS seemed to be only rarely the impediment to onboarding devs without FP backgrounds.
Pros are that, yes, it did have conceptual overlap with their backend (using Cats), and since most of their applications did the same form-based CRUD tasks just across different data sets in the domain, they had honed really efficient library idioms for rapidly building new apps with just a handful of type signatures. And they were indeed deploying a lot of apps to replace the legacy versions of their suite (a couple dozen per sprint).