To answer your question you can skip the files in use validation; it doesn't ever block you from proceeding and is only there to inform you if you might need to reboot AFTERWARDS.
There are many more situations where you must still reboot and it won't tell you (usually .NET Framework related) so you're always going to reboot no matter what. Besides, if you don't reboot now you'll need to do it next month when the next pack comes out because that IS a patch blocker.
But to address the elephant in the room even if you're patching just one or two servers then you should allocate more time than 30 minutes; 60-120 minutes is about right especially if you have AGs/FCIs/mirroring/replication and Enterprise features. If you have a few dozen servers you can compress that into about four hours because you'll be partly automating at that stage and it's pretty rare that they'll all fail with completely different issues.
The reason you need more time is you never know what's going on with an ESX host, temporarily slow SAN, or the bugs in 2012 they allegedly fixed recently with slow update installs. Or you somehow forgot to remove SSISDB from an AG first and now it's hosed and you need to fix it. Or the repeated failures from MS screwing up instances with filestream so you have to go into Add/Remove Programs and do a repair before reapplying the update. Or you need to wait for the AG to come back in sync after patching (easily 30 minutes on a busy server), failing over and doing the replica.
What basic health checks have you automated? It takes a few minutes per server to run all the AG policy checks. If you're doing it by hand it's more; validating DQS MDS SSRS SSAS have all come back up and aren't throwing stupid errors.
I can fairly confidently say that while it's useful to test on QA first there has been many, many a time a patch has only failed in PROD because someone somewhere sometime did somethings differently.
Anyway the list isn't endless but it's definitely more than 30 minutes. You don't want to be looking at the clock while you're trying to fix a disaster just because you under quoted with a short time limit. I understand managers want to hear it - and that's why DBAs get paid the big bucks because we need to say No.