Leaving files open degrades application performance and increases the risk of unexpected side effects. Using open as a context manager will close it automatically for you.

Computers have finite resources, including limits on how many files can be simultaneously open. Therefore leaving files open consumes more finite file handles than necessary. Under extreme conditions this could exhaust the number of allowed open files causing an "IOError: Too many open files" exception to be raised. Additionally, leaving files open consumes finite memory for longer than is necessary. Therefore for performance of the application it is preferable to closing file after finished with them.

Python's garbage collection will eventually close dangling unclosed files, but "eventually" should raise a red flag if the goal is to write predictable software. Indeed, Python3 and Cpython might implicitly close the file the instant they're no longer being used, while others might not for a long time. Under some conditions it might not happen at all. When pairing this problem with the zen of Python's Explicit is better than implicit, it's clear that it's better to not leave files open.

Python can also be fuzzy around exactly when file changes are committed to disk: the data may not be written to disk until the file is closed:

# bad: maybe not written to disk yet as the file was not closed
open('foo.txt', 'w').write('foo')

# also bad: maybe not written to disk as the file was not closed
f = open('bar.txt', 'w')
f.write('bar')

# better: written to disk when the file closed
f = open('baz.txt', 'w')
f.write('baz')
f.close()

# good: written to disk when the file closed and code is neater
with open('qux.txt', 'w') as f:
    f.write('qux')

Windows (the Operating System) locks files opened by Python. This means leaving files open is not thread safe as one thread will lock the file preventing other threads from opening it - even if the other thread just wants to read from it.