While I haven’t done that I’ve had to mitigate those risks for companies before. The conduit between formalism and informalism is purpose.
Translate your test cases into purpose - what risks are these test cases trying to mitigate? In some cases you’ll find they have no discernible purpose, in some cases you’ll find they go into automation very easily, in some cases you’ll find that a whole raft of tests is trying to test for one thing.
When you have the purpose of the test cases you can craft a less-formal solution that covers that purpose. This could be a list of risks, a list of product areas or some other coverage map, a checklist of important things to look for, and so on.
Then you have the purpose of the test PLUS the power of exploration.
If you have to argue the point about deformalisation there are many advantages. Firstly, instead of thinking of issues you might no longer catch think of all the issues you could be catching that weren’t in the test cases! You’re not catching anything outside of the test cases (if the test cases are strictly adhered to). This means you’re doing a similar thing over and over, which means you won’t explore new risks or find new problems.
When you provide a purpose-driven interface for testers they tend to (in my experience) work better, faster, with more self-confidence, and with a sense of direction because they understand the purpose of their work. You also have less maintenance cost because formally describing a human process is so difficult and whenever your product or project changes you have to re-describe that process or you end up with test cases of very little value. If you have a purpose-driven process then you simply adjust to whatever purpose you need, and when that purpose seems silly that is an indicator that you need to review your checklists/charters. Try looking through a test case suite and deciding on the value of your cases, and you’ll soon see the advantage!
So yes, you could possibly miss something that was in a test case. But you could do that already. Test cases are boring and are poor tools for communication, often written by non-experts (and test cases are really hard to write. It’s hard enough to instruct someone on how to do something in person!). This means that 10 different testers will interpret and process that test case in 10 different ways, which means 10 different kinds of coverage at 10 different levels. Some will skip steps, some will include extra steps, some will avoid what they don’t understand, and so on.
Think of test cases as searching a cave inch-by-inch with a high powered short-range flashlight, and deformalised testing as searching a cave room-by-room with a large long-range lantern. Now imagine you gave the people with lanterns a map showing key areas to search (risk catalogues, checklists, etc).