The article you mention is about modularity in general, and it would apply equally to structured, functional, and object-oriented programs. I have heard of that article before from someone who was a big OOP guy, but I read it as an article about programming in general, not something OOP specific. There is a famous article about functional programming, Why Functional Programming Matters, and the first sentence of the conclusion states "In this paper, we’ve argued that modularity is the key to successful programming." So the answer to (1) is no.
Well designed functions don't assume more about their data than they need to, so the part about "intimately aware of the data" is wrong. (Or at least as wrong as it would be of OOP. You can't program strictly at a high level of abstraction and ignore all details forever in any paradigm. In the end, some part of the program does actually need to know about the specific details of the data.)
Data hiding is an OOP specific term, and it isn't exactly the same as the information hiding discussed in the article. Information hiding in the article is about design decisions that were hard to make or are likely to change. Not every design decision about a data format is hard or likely to change, and not every decision that is hard or likely to change is about a data format. Personally, I can't see why OO programmers want everything to be an object. Sometimes, a simple data structure is all you need.
Edit:
I found a relevant quote from an interview with Rich Hickey.
Fogus: Following that idea—some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding?
Hickey: Let’s be clear that Clojure strongly emphasizes programming to abstractions. At some point though, someone is going to need to have access to the data. And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t. This is in addition to the other losing that occurs when simple information is put into classes. To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt. And if they are rational, they know when they make a decision based upon something that can change that they might in the future need to adapt. So, it’s a risk management decision, one I think programmers should be free to make.
If people don’t have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers.
Best Answer
Haskell is most closely related to the ML family of languages. This includes things like OCaml, of course, but also F# on the .NET platform. These languages share with Haskell the foundation of the type system and how data is used--algebraic data types, pattern matching, type inference, etc. They can differ substantially from Haskell on other points, of course--most MLs are strict and impure, to start with, and the popularity of Haskell as a vehicle for research in type systems and language design means that most ML-style languages tend to have less powerful (but potentially easier to understand) type systems. It's probably safe to say that while you may miss some things about Haskell, particularly at first, most Haskell programmers would probably feel comfortably at home in an ML pretty quickly, at a basic getting-things-done level. If you want a language with the same overall structure as Haskell, an ML is your best bet.
The functional side of Scala draws heavily from the ML tradition, as well, and also pulls in some advanced type system features familiar from Haskell, as well as a more standard OOP system integrated with the above. While OO in ML-style languages tends to be approached as more of a "model OO with basic functional tools" Scala lives and breathes Java-style OO. This has benefits for Java interop, as you might imagine, and presents more familiar working environment for OO programmers. However, coming from a Haskell background, you're more likely to be annoyed by ways that blending things together in Scala makes functional idioms clumsier, and find most Java APIs to be badly designed and needlessly difficult to use. So if you want something with a sophisticated type system that permits direct translations of many things in Haskell (with some extra syntactic overhead) and don't mind compromising on functional style, you might enjoy Scala.
Finally, while it may seem odd to consider, Clojure actually has a lot of things in common with Haskell at a more philosophical level. Most of what you'll find in Clojure's approach to state and values vs. identities is very close in spirit to what Haskell formalizes through the type system. Correspondingly, Clojure emphasizes Java interop to a smaller degree and doesn't worry as much about dragging in OOP, so in some ways Clojure's approach to functional programming itself may be closest to what you're already familiar with. I think it's telling in this regard that, to the best of my knowledge, Clojure is the only language besides Haskell that has an implementation of STM that's simple, effective, and just works. On the other hand, Clojure comes from the Lisp tradition and thus lacks the static type system and emphasis on algebraic data types and pattern matching found in ML-influenced languages. And of course it's a Lisp, which is itself a negative to some people (though I really don't know why).
Speaking for myself, with the disclaimer that my first experience with functional programming was in Scheme, I'd probably lean toward Clojure, with OCaml a likely second choice.