> I would say almost all Windows console programs does use 
> console's encoding for input/output because otherwise 
> user wouldn't be able to read it.

While some programs do use the console codepage, even when writing to a pipe or disk file -- such as more.com, reg.exe and tasklist.exe -- it's no where near "all Windows console programs". As a counterexample, here's a list of Microsoft utilities that always use the OEM codepage (CP_OEMCP) when writing to a pipe or disk file:

    attrib.exe
    cacls.exe
    doskey.exe (e.g /history)
    fc.exe
    findstr.exe (calls SetFileApisToOEM)
    hostname.exe
    icacls.exe
    net.exe
    qprocess.exe (also to console)
    quser.exe (also to console)
    sc.exe
    tree.com

To further ensure that we're on the same page, the following demonstrates what happens for creation flags DETACHED_PROCESS, CREATE_NEW_CONSOLE, and CREATE_NO_WINDOW in Windows 10:

    from subprocess import *

    DETACHED_PROCESS = 0x00000008
    CREATE_NEW_CONSOLE = 0x00000010
    CREATE_NO_WINDOW = 0x08000000

    cmd = ('python -c "import ctypes;'
           "kernel32 = ctypes.WinDLL('kernel32');"
           'print(kernel32.GetConsoleCP())"')

    >>> call('chcp.com 65001')
    Active code page: 65001
    0
    >>> check_output(cmd, creationflags=0)
    b'65001\r\n'
    >>> check_output(cmd, creationflags=DETACHED_PROCESS)
    b'0\r\n'
    >>> check_output(cmd, creationflags=CREATE_NEW_CONSOLE)
    b'437\r\n'
    >>> check_output(cmd, creationflags=CREATE_NO_WINDOW)
    b'437\r\n'

The test was run with a U.S. locale, so the OEM and ANSI codepages are 437 and 1252. With DETACHED_PROCESS there's no console, so GetConsoleCP() returns 0. That's the value of CP_ACP, so ANSI is the natural default for a detached process. CREATE_NEW_CONSOLE and CREATE_NO_WINDOW cause Windows to load a new instance of conhost.exe, which is initially set to the OEM codepage.