Your security barrier is the firewall in the router, plus whatever encryption you apply to comms outside it. As long as you get that right your ISP can't see what you are doing apart from the to/from addresses on your packets (which can't be hidden, obviously).
ISPs generally push their own managed router/firewall at you because that way when something isn't working you don't wind up with arguments about who's fault it is, and the ISP can troubleshoot your router. But in my experience they have no problem with you unplugging their device and plugging your own in instead.
I haven't seen an ISP which does the ONT and the router in a single box. Its theoretically possible, but would be a bad idea for several reasons. One is security, as you say. Another is that the fibre can't be extended with more wire, unlike a copper phone line. So the ONT tends to be a small wall-mounted box with an Ethernet jack in it. That way your Wifi access point isn't stuck low down next to your front door or something.
* The time you spend managing and supervising, including desk-checking the stuff they send out, because it goes out under your name and you are only as good as your last job.
* IT costs, and office space if they aren't working from home.
* Liability insurance in case they screw up. (Not certain about this: maybe you just trust that your company is a sufficient legal firewall because its only asset is you).
I remember back around 1990 hearing that for my big company employer putting a coder in a seat in front of a computer cost roughly twice their salary. That's still true today.
a legacy of EU membership, but I doubt the government has any will to change it
* Back in the 60s they got a big IBM computer to do some stuff. Then later on they needed to do other stuff. The old computer was too expensive and difficult to replace, so they got a new VAX or something to do the new stuff and talk to the old mainframe. Then some PCs got added to do more stuff, and so on. Today the back end consists of many different systems of different ages all talking to each other using different protocols that were designed against different requirements. Newer systems are forever being patched and updated to cope with new requirements, while the code for old requirements lurks waiting to be accidentally reactivated. Each of these systems has its own specialists for care and feeding, but nobody fully understands the whole thing. When something goes down there are not many people who can diagnose the fault and get it back up.
* Government contracts have lots of rules around them to ensure value for money and prevent corruption (see the UK COVID PPE fiasco for what happens when you try to cut these rules out). But the size and complexity make even bidding for a big contract very expensive and complicated, so it tends to be the preserve of a few big companies who chose to specialise in it. Their core competence is winning these contracts, not delivering on them later.
* These rules mean that everything has to be specified in detail up front, so that everybody knows what is supposed to happen. But this makes the whole thing horribly inflexible. As new requirements emerge from the woodwork there is a continuous process of renegotiation.
* The UK civil service is based around the "cult of the gifted amateur". Senior managers are rotated around departments every few years. So the person who kicks off a project is rarely the person who sees it through. Everybody gets to blame someone else for failure.
* When one of these big contractors fails to deliver, the Government has to chose between suing to get their money back (or some of it) in a few years, or getting the at least part of the system they actually need at a higher price. The government doesn't need the money, it needs the system. So the contractor gets to carry on regardless of failure.
* Humans are very bad at managing small risks with large consequences. Many big disaster stories have at their heart someone who decided that the risk was too small to be bothered with.
As to your "not a complex system" remark, when a system is built for 60 years, piling up new rules to implement new legislation and needs over time, you tend to end up with a tangled mess of services all interdependent that are very difficult to replace piece-wise with a new shiny architecturally pure one. This is closer to a distributed monolith than a microservices architecture. In my experience you can't rebuild such a thing "in 3 months". People who believe that are those that don't realize the complexity and the extraordinary amount of specifics, special cases, that are baked into the system, and any attempt to just rebuild from scratch in a few months hits that wall and ends up taking years.
https://wiki.c2.com/?WhyIsPayrollHard
Its from a different domain, but it gives you a flavour of the headaches you encounter. These systems always look simple from the outside, but once you get inside you find endless reams of interrelated and arbitrary business rules that have accumulated. There is probably no complete specification (unless you count the accumulated legal, regulatory and procedural history of the DVLA), and the old code will have little or no accurate documentation (if you are lucky there will be comments).