Advantages of WFS over GeoJSON/KML?

Keep in mind that WFS is already a service which returns its data format (mixture of OGC standards). GeoJSON and KML are only a data format, you'll have to build the service to return the data.

So included with WFS are already advanced filtering capabilities such as temporal filters, spatial filters (intersect, touches, overlaps...) as well as logical and comparison operators...and on and on. Yes you can specify to reload results for a BBox as well as the user navigates the map. This is all out of the box. Then ofcourse it's a widely used standard that many servers, clients and applications can read by allowing them to automatically query this data as said.

So the question you should ask yourself is are you going to want to expose this data to other clients, applications and servers? Will your "Give me all features of layer L between X1,Y1 and X2,Y2" service be enough? Is that all you need? If it's all you need then no reason to go with WFS. The GeoJSON or KML option will probably be faster without all the overhead. But if you're going to want to do advanced filtering in the future SOA style, WFS is the way to go.

I recommend you to read the spec. The biggest pro of WFS is that it is official and standardized way to access vector data. That means when you use WFS, you do not have to reinvent to wheel (e.g. what should happen when two people edit the same feature at the same time?). It is also much easier to share data over WFS than using GeoJSON or KML (again, you do not have to write a function that returns the data user asked for as it is already a part of WFS spec).

If you are about to serve layers for read-only access, you could go with WMS. It should be totally OK for your purposes.

WFS gives your client (OpenLayers) the option to perform its calls using different Strategies for the WFS Calls:

BBOX: reads new features when the viewport invalidates some bounds.
Cluster: for vector feature clustering.
Filter: for limiting features that get added to a layer by evaluating a filter.  The strategy maintains a cache of all features until removeFeatures is called on the layer
Fixed: requests features once and never requests new data
Paging: vector feature paging
Refresh: refreshes the layer.  By default the strategy waits for a call to refresh before refreshing.  By configuring the strategy with the interval option, refreshing can take place automatically
Save: commits newly created or modified features.  By default the strategy waits for a call to save before persisting changes.  By configuring the strategy with the auto option, changes can be saved automatically

The BBOX Strategy is commonly used. The Vector Layer will only request features from WFS that are in the viewport and as the viewport is changed, additional features are automatically loaded transparently.

As CaptDragon stated and I mentioned in your previous question the numbers of features will kill OpenLayers, most likely, or make the user experience untenable.

You could stuff your data into an MSSQL database, then write a Server Side routine to return data via Ajax calls and update the layers yourself. You Client provides the Viewport bounds in the Ajax Call. The database has to be spatially aware for this to work.

WMS would generate tiles from the same data-source. The advantage is very rapid implementation, server side styling and no downloading of data to the client for display, other than the tiles. You can also use WFS with WMS to get feature information when users click on a point.

It would also be possible to serve the data from a shape file instead of a database in all these scenarios.