This is a huge change. 

https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 states:

• 153 files changed
• 5384 lines of code added
• 14918 lines of code removed

Granting the argument that above commit includes test routines and not directly/entirely related source changes to this matter as well, I would like to highly suggest you to re-rate an re-evaluate your feelings towards the changes made. If it's even remotely near to a 'mild inconvenience' and/or 'needs time to get used to it' - don't even try to back-port. Even if you would revert these, this will most definitely become a bottomless pit in future version updates.

Furthermore, about Odoo saas~18.3+e (unless you would be running a 18.3 build on your own server):

• a community or third-party module can not be installed in Odoo Online.
• developer customization is hardly possible in general, since every change would need to be done directly on the database without actual source code access. The magnitude of above change will make any reset attempt close to, if not strictly, impossible.
• configuration that reverts to the previous interface does not appear to exist.

Since an Odoo Online subscription entitles you to direct support from Odoo - even though the help desk will tell you pretty much the same, I'm sure - you may provide your feedback to these changes and suggestions based on your use cases and workflows, to trigger a potential consideration in future optimization attempts on that view.
You may do so here: https://www.odoo.com/help

Another grasp at straws - theoretically - can be the OCA - Odoo Community Association - or any 3rd party vendor feeling the need to provide a module to reset this change. In any case, if such a module would be released, you will not be able to utilize it in an Odoo Online saas setup. You would need to (also for an own custom development) need to switch to a custom plan. 

Frankly speaking, I doubt the efforts involved in reverting and maintaining this in future will be be worth the cost.

Lastly, next to the change log below, I would like to suggest you to evaluate potential changes prior to updating your database. You may to so at https://demo.odoo.com or on https://runbot.odoo.com. If a certain release does not work for you, you may await the next version update or further iterations on it and jump to the next version when it works best for you and your business. An Odoo custom plan using odoo.sh for hosting would come in handy for this scenario as well, because it would provide you with a 'Staging' environment (a copy of your live environment not productively active) to test changes with your own data. It should be mentioned however that odoo.sh does not provide a possibility to run sub-releases (i.e. 18.1, 18.2, 18.3) but major releases only (18.0, 19.0). Customization however could bring you - if cost isn't a factor to consider - close to 'up to date'.

The notes on this commit state:

[IMP] account, account_accountant: new bank reconciliation widget
This commit introduces a revamped kanban view to process the bank statement
lines and reconcile them with existing invoices/bills, or help the users to
create the correct journal entry.

RATIONALE:
The previous reconciliation widget was not really user friendly, and was bloated
 with a lot of advance features for niche use cases.

IMPLEMENTATION DETAILS:
* account.reconcile.model
  - rule_type: writeoff_suggestion and invoice_matching entirely removed. Those
    features are now directly hardcoded, users can't modify the sequence or
    tweak the invoice matching algorithm anymore. We belief this was way too
    advance and that people modifying the existing rules (and default behaviour)
    would more likely break something rather than help the processing of their
    statement lines
  - partner mapping: although it's not possible anymore to do it on the partner
    categories, it's still possible to define a partner mapping by creating an
    account.reconcile.model with match_label & match_label_param, and a single
    counter part item with the partner_id set and no account_id
  - deleted fields: rule_type, matching_order, match_note, match_note_param,
    match_transaction_details, match_transaction_details_param,
    match_text_location_label, match_text_location_note,
    match_text_location_reference, match_same_currency,
    match_partner_category_ids, match_partner, past_months_limit,
    decimal_separator, show_decimal_separator, partner_mapping_line_ids
    (+class), allow_payment_tolerance, payment_tolerance_type,
    payment_tolerance_param, counterpart _type, journal_id, number_entries
  - field auto_reconcile changed name & type (was boolean): it's replaced with
    the selection field 'trigger'
  - to_check boolean: would now be implemented with next_activity_type that you
    can set on the account.reconcile.model

* account.bank.statement.line
  - Revamp of the whole javascript with a clear subdivision into
    multiple components. We used a Kanban view that we completely override for
    our needs which are that each kanban record will display the information of
    a bank statement line (belonging to a journal) that we can unfold to show
    more information. When unfolding the bank statement line the user will have
    access to different buttons allowing him to directly modify the move behind
    the bank statement line (adding new line, delete some, editing them, ...)
  - The old bank rec widget was using two python file bank.rec.widget and
    bank.rec.widget.line that were temporary models to display a representation
    of the move before being validated and once it was validated the move was
    changed. Those two classes were removed.
    We now change directly the move because we want an auto validation. It means
    that everytime a new line is added a reconciliation process is done.
  - To link the move line of the bank statement line with the move line chosen
    in the reconcile search view and also to trigger the reconciliation
    process, we used a manyToMany field compute non stored with an inverse.
    Everytime the field is written on, the reconciliation plan will be
    triggered. It allows to have a link between reconciled entries without the
    need of a stored field since we benefit from the partial reconcile table.
  - Delete: bank.rec.widget, bank.rec.widget.line, views linked to
    bank_rec_widget that are not used anymore