What's wrong with using JSONModel for data from OData services in UI5?

I had to develop (with a teammate) an application which contains mainly a table with a dozen of filters, and rows loaded from an OData service with roughly 400k entries. Since we had to frequently upload the model without storing changes into the server, and we wanted a user to immediately see the results of the changes he makes, we decided to build sap.ui.model.json.JSONModel at the start of the application, which loads its data from sap.ui.model.odata.v2.ODataModel.

We found out that, in this way, the application was significantly faster than going with the direct OData binding approach, and our trick made the app work perfectly.

So, our question is: are there any drawbacks in doing what we did? Bear in mind that we both don't have much experience with the SAP Fiori world, and that in our application users don't have to write data nor create new entries in the table, they will only view data, use some filters, sortings, and download the CSV once they filtered the table.

EDIT: Here's the link for the repo containing only an mcve, where I used Northwind OData, and do problematic operations directly on the ODataModel, without using an intermediate JSONModel. The crucial operation is a filter that displays only selected item of the table: you can change Northwind OData to any service you want and see that if the number of rows of the table grows substantially, this operation requires a lot of time. Sap UI5 version used: 1.84.0

Solution

I'd reconsider loading 400.000 entries at once. This roughly corresponds to 10+ MB of data load when the app launches.
About the "trick"..:

our trick made the app work perfectly.

The main difference between server-side models (like ODataModel) and client-side ones (like JSONModel) is that server-side models are aware of the query specification implemented by the backend service and thus can let the client (UI5) optimize the runtime behavior, while writing less code (often declaratively), and on top of the client-side features. In our case, ODataModel also supports client operation mode:
```
"models" : {
  "": {
    "dataSource": "myODataService",
    "settings": {
      "defaultOperationMode": "Client"
```
This will also load all entries at once for the table without having to use an intermediate JSONModel. Sorting, filtering, etc. will all happen on the client side. But again: the operation mode should be selected depending on the amount of data, target users, devices, and use cases.

Since ODataModel even supports exporting data to another format, I see such intermediate JSONModel as a pure overhead when dealing with data from an OData service.