It's really a situational thing that you want to look at per-table or per-index, and you really need to find out what's in production before taking any action. When in doubt, use what's in production in the other environments, too, even if it means using a bunch of crazy settings. You just can't get a good feel for how production will behave if things are different in test or dev.
Anyway, the general recommendation to leave auto-update stats turned on (
STATISTICS_NORECOMPUTE = OFF, which is the default) is for safety reasons, because if this is turned off and nothing is manually updating the stats, the result could be really horrendous execution plans that never change after they're first created (and don't get invalidated for other reasons later on).
You said auto-update stats is turned off for most indexes (I think I originally misread that as all, not most). For the indexes with auto-update stats still enabled, does this setting make sense given the activity on those tables? I would expect that these are higher-activity tables. It's possible a lot of work went into figuring that out, and it may be worth keeping (or strongly considering) those settings. At the very least, make a note of which stats these are, because that information could come in handy down the road.
Thinking about it more, I will say that the current strategy does make sense. Is it better than leaving auto-update stats on for everything? It seems someone thought so, to the point that it was worth the ease-of-management tradeoff of having an associated SQL Agent job.
If the idea was to have fresh stats available without blocking queries (like this), you could consider turning auto-update back on for everything, and then also turn on
AUTO_UPDATE_STATISTICS_ASYNC as well. Then probably change the job schedule to run once/week instead of daily, as you still do want stats updated
WITH FULLSCAN periodically.
I might just leave it, though, as you probably have bigger fish to fry if the indexes themselves are different between environments, and the stats rebuilds aren't too painful. What's there now does make sense; you just need to make things consistent across environments. It's probably marginally better than the simpler settings I suggested, at the expense of more work being done. But find out what's in production, tend towards using that, and move on to more important things; revisit this when you're at the point of needing to more finely tune performance -- the best stats in the world won't save a query that's missing a critical index.