I am in favor of removing file:// support.

Note that you could continue supporting file:// for the network service case without too many changes via a glorious hack to ProxyConfigMonitor::OnProxyConfigChanged [1].

The idea would be to remove file:// support for PAC from the network service (PacFileFetcherImpl) as you plan to, but then also translate the proxy_configs produced by the browser process (ProxyConfigMonitor::OnProxyConfigChanged) such that file:// URLs get expanded to a data:URL containing its contents.

The main caveats would be:
  (1) On disk changes to the PAC file wouldn't be noticed, as we no longer poll it
  (2) Extra memory usage as the entire file is kept in memory as base64

This could be an option for supporting file:// for longer via a Chrome Policy if it turns out we need it and it is causing problems with servicification. That said, I would be surprised if enterprise was actually relying on file:// for PAC scripts.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf5fddf9a8fd257fe47126a29f45410405025faa

commit bf5fddf9a8fd257fe47126a29f45410405025faa
Author: Eric Roman <eroman@chromium.org>
Date: Tue May 08 22:48:30 2018

Add a histogram showing which URL schemes are used by explicitly configured PAC scripts.
Bug: 839566

Change-Id: I51eb05bc52587d84592966870387ccae9d8db5d7
Reviewed-on: https://chromium-review.googlesource.com/1044751
Commit-Queue: Eric Roman <eroman@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Jay Civelli <jcivelli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556992}
[modify] https://crrev.com/bf5fddf9a8fd257fe47126a29f45410405025faa/net/proxy_resolution/proxy_resolution_service.cc
[modify] https://crrev.com/bf5fddf9a8fd257fe47126a29f45410405025faa/net/proxy_resolution/proxy_resolution_service_unittest.cc
[modify] https://crrev.com/bf5fddf9a8fd257fe47126a29f45410405025faa/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/bf5fddf9a8fd257fe47126a29f45410405025faa/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8d523527ff00cfdeaf792a52a3a174d7207c2c16

commit 8d523527ff00cfdeaf792a52a3a174d7207c2c16
Author: Jay Civelli <jcivelli@google.com>
Date: Tue May 15 23:17:37 2018

Disable PAC scipt file URLs

Disables support by default for PAC script file URLs when network
service is enabled. This is in preparation for sandboxing the network
service which won't have access to the file system anymore.
Eventually we'll disable it without the network service.

Bug: 839566
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: Iee68c35615f3566f0eac7a5d9ae39a28eb3d1b8d
Reviewed-on: https://chromium-review.googlesource.com/1043097
Commit-Queue: Jay Civelli <jcivelli@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558877}
[modify] https://crrev.com/8d523527ff00cfdeaf792a52a3a174d7207c2c16/chrome/browser/net/network_context_configuration_browsertest.cc
[modify] https://crrev.com/8d523527ff00cfdeaf792a52a3a174d7207c2c16/services/network/url_request_context_builder_mojo.cc

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

I was hit by this change in Canary and it was really hard to pinpoint because proxy information was removed from chrome://net-internals and the problem wasn't indicated otherwise.

My use case was local .pac file with a complex set of rules directing certain domains through local DeleGate (http://www.delegate.org/delegate/SOCKS/) instances which in turn routed traffic to real SOCKS proxies that require authentication. 
This effectively allowed me to seamlessly use password protected SOCKS proxies with pac files.
Since everything was run locally under my control the security implication were of little concern.
With the file:// support removed I now need another local server, an HTTP one just to serve the pac file over http://

Do you have any plans to introduce any flags to allow file:// scheme, new local proxy options or other workarounds?

Where are you setting a file:// URL from?

One workaround could be to switch to a data:URL, although you could hit the command line length limit if your script is big:

--proxy-pac-url='data:application/x-javascript-config;base64,'$(base64 -w0 /path/to/pac/script)

Another workaround would be to set the script via a Chrome extension.