Please consider, that Harper's needs for teaching an introductory CS curriculum class are very different from the needs of a real life project. His job is to teach fundamental concepts (e.g. modularity, parallelism, induction) to freshmen. As such it is very important, that the language (and paradigm) choosen can express these concepts with as little ceremony (syntactical and conceptual) as possible. Familiarity, tool support, available libraries, execution performance etc. are completely irrelevant in this context. So please keep this in mind when considering the following...
The view that OO is anti-modular results from the large number of dependencies to other classes even objects of well designed classes tend to end up with. That this is a problem - even in the eyes of proponents of OO - becomes clear when you look at the proliferation of Dependency Injection frameworks, articles, books and blog posts in the last years (also the rise of mocks and stubs is interesting).
Another hint is the importance of Design Patterns and the complexity of implementing them - as compared to some other programming paradigms - e.g. Factories, Builder, Adapter, Bridge, Decorator, Facade, Command, Iterator, Mediator, Observer, Strategy and Template Method and maybe the Composite are all in some way related to improving the modularity of OO code.
Inheritance is also problematic (e.g. Fragile Base Class Problem) and (subtype) polymorphism seduces one to spilt up the implementation of an algorithm between multiple classes, where changes can ripple through the whole inheritance chain (up and down!).
The charge of being anti-parallel is related to the emphasis of state compared to computation (aka. mutability vs. immutability). The former makes it more involved to express dependencies of subcomputations (which is Harper's take on parallelism!) as you usually can't infer from the location the state is managed (aka. the file, where the instance variable is declared) which outside actors will change it at what point in time.
An emphasis on immutability and computation makes expressing dependencies of subcomputations much easier, as there is no state management, just functions/computations which are combined at the place where you want to express the dependencies of subcomputations.