I retract my previous statement "Splattering .py files in ~HOME is not tremendously better than doing the same in the executable directory." and agree that when started with the default Windows icon, IDLE should start in %USERPROFILE%. 

Discussion for #25450 clarified some of the practical issues.  Windows icons have a Shortcut tab with a Start-in field.  We should like to put %USERPROFILE% there, but this does not work -- msg253393.

Steve Dower suggested to instead add a new command line option to set the starting directory for code entered in the shell window.  (IDLE currently uses getopt with
  USAGE: idle  [-deins] [-t title] [file]*
         idle  [-dns] [-t title] (-c cmd | -r file) [arg]*
I suggest adding option '-w path' (w for 'working directory' or 'workspace', d already being used).  Any better ideas?  Like d, s, t, c, and r, the new option would imply -i, open a shell window.

Shortcut tabs also have a 'target' field.  For 3.5, this is an editable command line.  I tested that adding "-t %USERPROFILE%" changes the Shell title accordingly.  Steve has already change the installed icon.  

Users could copy the icon and add a subdirectory, such as 'python', where they put python code.  I presume users on other systems could do the equivalent, so the benefit of this is not limited to Windows.

For prior Python versions, the Shortcut 'target' is a read-only grayed-out 'Python x.y.z (nn bits)'.  I do not know how this is resolved to running IDLE with the specified binary, but it likely would not be easy to change to the 3.5 editable field version (and not create other problems in the process). So I will not even ask MVL, the previous Windows installer maintainer, to do that.

idlelib/idle.bat was added to get around the inability to edit this field. (ADD DOC for this.)  So the new startup option could be used by Windows users to start older IDLEs in their home directory.