First, I would say it is not a "x vs. y" issue - the concepts are orthogonal. The Java and C# implementations that we have been working on both use OOP, but they distinguish between data objects and "process" objects (that extend Threads). FBP has been described as one of the earliest OOP systems, because of the way it manages data, but has always had the concept of configurable modularity as well, which most conventional OOP systems have yet to discover!
A better distinction is between single-threaded and multithreaded approaches. Most people regard multithreading as error-prone and hard to get right, so a number of writers have assumed that FBP must suffer from the same problem, whereas FBP buries the multithreading in the infrastructure, so that the coder does not even have to think about it. Instead of the single-threaded approach to most apps, the FBP designer thinks in terms of transformations being applied to data streams. If you were designing a Coca-Cola bottling factory, how would you do that processing synchronously?!
The FBP paradigm is, in our experience, simpler and more maintainable than single-threaded code for large, complex applications. However, there are a few, relatively simple, applications which your prof might find thought-provoking - one is described in TelegramProblem (it contrasts a conventional OOP collaboration diagram with the (much simpler) FBP diagram), and another is buried inside SameFringeProblem (look for FlowBasedProgramming). Of course, you may have to find your own ways of helping your prof through the paradigm change - I would be interested to hear what arguments you come up with!
I am rereading the chapter of my book on this topic, and there are a number of other points which seem worth bringing up, but I am sure you have seen them already. The last few paras in that chapter, starting with "OO research and development", describe a number of projects that are making the right distinctions, and I'm sure there have been more since the book was written. The distinction between "active" and "passive" objects seems to be holding up pretty well, and as we move towards more and more distributed applications, I don't see any other way to go!