I've pondered adding file download capability to the browser because it has been mentioned before. There are a number of issues, as I see them:
(1) Adding file download capability makes the program bigger, thus decreasing the size of web page that the program can download and render (the web page has to be held in memory). At the moment the program can just about download the chess web page; adding any extra capability and it won't be able to handle that. It might be possible to use some sort of program overlay to load the code to download a file then reload the browser code, but that gets difficult when people want the program in different types of cartridge etc. ...
(2) If the requirement is just to handle downloads from an FTP site then that could probably be handled by a completely separate program. If just 'browsing' an FTP site then that could be handled using a video text mode, rather than rendering pages using a video graphics mode (so a smaller, faster program).
(3) I'm not sure how the program would handle all the different file types (EA3, EA5, BASIC, Ext BASIC, relative and sequential files, ...). It might be that a TIFILES header or similar provides all the information needed to recognise the file type. If a TI file needed some sort of 'processing' to put it into a particular format suitable for upload then download, that's an impediment to 'just anyone' uploading files. Which brings me on to ...
(4) How many people would actually use it anyway? After the initial "that's cool", it might well just fade into non-use. So a lot of work for something used by people you could count on one hand. Unless done for one's own personal enjoyment of course.
(5) Is file download functionality something that the TIPI devs might want to add to the TIPI itself? A new TIPI call with URL and storage device name parameters, and the TIPI handles it all?