I've been on teams where I felt extremely comfortable using long functional-style chains like items.map().zip().flatMap(), and I've been on different teams where every time I want to use even just a map() I stop and consider if it's worth it.

Which ends up being more understandable in the long run depends a lot on the engineering culture of the team and the company. Do we hire a lot of folks with functional programming experience? Are we primarily an object oriented shop? Do we reorg often, or do specialists get to stick with the same project for years? I know James is super into macros but Edna hates all programming languages despite being proficient at several of them. Which of them is most likely to touch this code in a year? Neither?

If you care about these decisions (and many people don't, which is a valid choice if one I disagree with) it will behoove you to pay attention to how your colleagues code and how you yourself code, and notice the differences. A little bit of effort now will go a long way towards avoiding a nasty rewrite in 3 years when you're gone and everyone decides understanding your work is more effort than replacing it.

There is plenty of code that I have gone out of the way to test and rewrite with newer available conventions, because I recognized that no one knew how to maintain it anymore. In many cases, if you're going to consider a nice big code golfy FP chain in a code base that doesn't have it...

Just extract it into a standalone method. Overhead's probably worth it.