Zombifying a nitwit, then curing it causes it to become an unemployed villager who does not eat or sleep

Both your arguments depend on defining "nitwit" as a profession, but it isn't one, at least not in Bedrock (or Java either, I think). The vanilla behavior pack implicitly defines a hierarchy for villagers in which the top level breaks them into three groups. Two of these groups correspond to babies and nitwits; the third corresponds to employable villagers. The latter are initially called "unskilled" internally, but once they acquire a workstation their internal label gets changed to their profession name, their behavior is enhanced with a more refined schedule, and additional behaviors are added for certain professions. Babies and nitwits cannot receive these enhancements, so they're distinct from professions.

I'm not sure how using the described behavior to convert a nitwit to a regular villager can be described as an "exploit". Nitwits don't spawn frequently enough to provide a significant numerical advantage, and most babies grow up to be professional workers, so if using nitwits this way is an "exploit", isn't breeding baby villagers an even bigger one?

I have linked related tickets reporting issues with the skins of zombie villagers. They have already been passed to the developers, so eventually they should give us a verdict on the intended results of curing zombie villagers. This report will depend on exactly how those other tickets are resolved, so I'm not sure what to do with it at the moment. I'll consult with Mega_Spud.

While I agree that it’s a fairly minor exploit in comparison to many other game mechanics, things should be brought to parity as much as possible, as the devs have made it clear that this is one of their main goals for the future of the game. If indeed baby villagers and nitwits have a similar structure in the vanilla behavior pack, then nitwit zombie villagers should also have this similar definition like baby zombie villagers. 
Here’s how the Minecraft wiki describes the java mechanics:

In Java Edition, if the villager is not locked to a profession (i.e by trading with it once), the villager is unemployed unless it was a nitwit, in which case it remains a nitwit; if it was locked to a profession it will keep both that profession and trades.

I'm aware that it works that way in Java and that parity is a goal, but it's an oversimplification to say that "things should be brought to parity as much as possible". Obviously, there should be parity in matters such as how big a creeper's hit box is, and just as obviously, asserting that trivial differences that don't affect gameplay, such as the precise pattern of a creeper's texture, is taking parity farther than is reasonable.

One thing that people often don't understand is that when the developers agree to honor the parity goal in some respect, they're voluntarily limiting themselves in how they can solve certain kinds of problems that might come up during new feature development. For example, if they agree that exactly when and how a player drops their inventory when they die should be identical in Java and Bedrock, that could complicate or even block a future feature that alters how player drops work (such as netherite armor floating on lava). And because they're written in vastly different languages, a certain precise implementation in one platform might be very hard to reproduce exactly in the other. So we as players need to leave the developers some wiggle room and not insist on parity of tiny details just because it makes it easier for us to remember the rules of play.

This issue lies somewhere between the parity extremes, so whether it's a reasonable target for a fix is vague enough to be a judgment call. My own feeling is that nitwits converting into unskilled villagers doesn't affect gameplay in any material way unless you're trying to gather a lot of nitwits, and in that case why zombify them in the first place? My point is that we shouldn't be demanding "parity" fixes unless they change gameplay significantly, either by forcing us to do something an entirely different way, or by making one platform substantially more difficult than the other. Parity for the sake of parity is not the goal.