I'm going to assume you're not talking one simple single page utility, otherwise what I'm saying here is absolutely overkill and it's a little weird you'd have big enough testing problems to matter. But assuming you mean something close to a modern production system with a UI, i.e. multiple screens or tabs or panes or functions:
Re: UI, you typically decompose it into parts (the main menu is useful here, or a use case/requirements tree) so that it can be tested in parallel by multiple people. You'd rotate those assignments. If you weren't doing functional decomposition of your UI, you were probably already well off best practices.
Re: scripted manual UI tests, that's pretty much describing hosing your QA. That's no reason at all, it's Antipattern #1 to avoid.
Brittle UI scripts happen when people who don't understand Page/Object Model and other techniques around architecting and selecting UI tests build them. UI scripts are natually more fragile but if you're finding them brittle (i.e., the scripts actually do break enough to get a reputation and kill confidence) you're either trying to E2E stuff that you shouldn't be or you're writing them wrong and haven't mitigated their fragility according to best practice around abstracting the UI under test.
There is no excuse in the world for leaving a brittle UI script in place, and the mitigation for not covering with a UI script isn't manual scripted regression testing, it's unscripted exploratory testing, preferably guided. All that brittleness in the automation script is also confidence-killing in your manual script because it represents environmental unknowns or non-deterministic operations that were critical enough to break the script. The human has those too, so now they're not on the script you thought you wrote anymore. They make less noise and do their best but it's like an unconditional exception handler. Nothing likely got fixed, just covered up.
With exploratory, you acknowledge up front that they can use discretion, so you're not tempted to pretend it's a day over day regression test and build false confidence. It's not a valid regression strategy because people aren't that consistent, but it's an excellent new-bug finding strategy because you look at new features immediately, and approach old features in new ways to break your own boredom. You're probably doing "unintended exploratory" right now if you're trying manual scripted. That's a bad thing, has all the "not valid regression" and all the "false confidence" issues.
Best thing about moving away from manual scripted, you save a ton of money not trying to maintain a library of Step/Verify scripts that break Single Point of Truth by repeating the same flows all over the place and therefore don't maintain worth a damn. Instead you test against the docs, so you get to dogfood those too.
My strong suggestion, were you to consult with me for QA/automation, would very likely be to take 20% of your time and build better scripts to dig yourself out, assuming this is a process you're keeping around. I can't say that for sure because I don't know your company or product, of course, but around the time you have testing pain is around the time to do this.
Were I to use my typical strategy for resetting UI test it'd be:
1. Start by cutting all the non-P0 cases. Most systems end up with basically one P0 case per major advertised feature, almost always happy path, so that's usually less than ten things where if they don't work, you can't ship the app at all, no matter how much time it takes to debug. Automate those scenarios. That's now your core UI acceptance suite. If you make it very small and limit only to things that can never, ever break you may be able to even use it in CI.
On another note, while they aren't common at all anymore, record/replay UI automation systems are actually useful for this. With so few test cases you can scrap and re-record throughout the cycle if you need to. Just don't try to keep them past initial bringup, they're unmaintainable. At some point write them programmatically for long-term ownership.
2. Only introduce P1 UI automation if you can justify extra cost over P0 after letting it ride for a release cycle--P0 should be near-zero cost if you're past alpha, or you did them wrong and need to revise those first before multiplying the design errors. If you do introduce UI P1s, tag or suite them differently. They're your extended UI acceptance suite. Don't block builds with it, you can't fix the tests fast enough. Run them nightly (and no record/replay here).
3. Don't even bother with UI automating (or manual scripting) P2 and P3 stuff unless you do not have anything else to do and you want more test maintenance. For most it's a simple decision: you do, and you don't, respectively, so don't test those E2E.
4. Don't script negative tests outside simple partitions like boundaries/numbers/character types/etc. Domain-specific negative tests usually only test one narrow scenario. Chances are overwhelming that even if you have a defect they miss it, and if it's not in docced flow they don't tend to get fixed fast. Those are naturally P2/P3 unless they're app-market-killers.
5. Only script people for one-offs and short-term crutches, otherwise let them use their brains. Look up and implement guided exploratory and write up mission targets to cover the other areas manually rather than with scripts. Rotate those testers between different missions at least once per release, if not more often.
Edit: I will say that I have a soft spot for crowdsourced UI testing services if you have to script, because of the novelty guaranteed by a gig system and that they present to your process basically as meat automation. But generally, no, you're not better off with manual scripted. You'd be better off to skip entirely so you can be properly nervous about your lack of effective testing and weigh the need accurately.
TL;DR: You should review your processes, you're hinting at the exact mistakes people make that has had QA relegated to an expensive cost center in most companies. Yours sounds a little broken and you may have normalized that.