Mvc – Good design patterns within JavaFX — MVC

Yes, it can technically be done. No, it shouldn't be done. And yes, you're missing a bit of what the controller is there for.

The controller is there to decouple the View from the Model. The decoupling is beneficial because you should look at the View as almost throw-away code. As your UI technology changes, you want to minimize the rework required in generating a new View. The controller enables that decoupling and provides a place for your code that will live through UI technologies.

It works in reverse as well if you need to add to or change out your Model. All of the upstream changes will be contained within the Controller and your Views will be left alone.

The other risk is that while the View is very simple now, you have less guarantee that it will remain so simple throughout its life. By calling the Model directly from the (very simple) View, you've opened the door a bit to allow additional bad practice to creep in later when the very simple View needs to become not-so-very simple. A future developer will be tempted to make more Model calls from the not-so-very simple View instead of refactoring the code and interacting with a Controller.

You quoted the Wikipedia article out of context. It actually says:

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event.

A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate use case controllers).

So a Use Case Controller is a specific type of controller. It doesn't necessarily mean that's how you will organize your controllers, only that it is one way of organizing them.

Controllers can be organized by functional responsibility, department, or whatever organizational pattern makes the most sense for your particular requirements. There is no "standard" way of doing it.