Hi, Emily-

Some thoughts:

+ Thresholding has the usual tradeoffs: high threshold should give you more "reliable" regions, but fewer and smaller ones. Group ICA outputs maps of Z-scores. On an individual ICA, maybe Z>2.3 or Z>3 would be a good place to start; for larger groups, higher Zs would be better, methinks. When I looked at the original Functional Connectome Project (FCP, Biswal et al. 2010) ICA results, where they had >=1000 subjects in their group ICA, one would have to threshold the results >10 or so, I think, to see "networks" resembling more normal functional ones.
There really isn't a non-arbitrary way to threshold these kinds of things "optimally" because there is no metric/criterion for optimality-- probably the closest thing to it would be "show me networks of regions I expect to see together (based on other functional studies), but dooon't include bad little noisy bits!", and it is hard to quantify that deeply. This is one of the arbitrary aspects of using ICA results (the other being setting the number of components, which strongly affects how parts of the brain get grouped together into regions-- 29 vs 30 components could easily produce different networks).
In your output networks, you probably want local maxima to be individual islands, so that they are labelled as separate target ROIs when you track? Higher thresholds will tend to help with that property (at the aforementioned expense of some other regions).

+ For inflating: typically, in healthy humans, people threshold DTI FA values at >0.2 and track just within that realm, using the resulting mask region as a proxy for a WM mask. In general, that is a pretty good approximation. Target ROIs do not overlap/abut that FA-WM region will not be able to be "hit" by the tractography algorithm, so any practical target ROI must abut/overlap that.
Biologically, the GM sheet bounds on WM, but in MRI practice different things can affect having a GM ROI directly doing so: warping between spaces (and rounding errors/partial volume in resampling), or high thresholding (where GM near WM might have lower SNR/stats values for some reason like partial voluming, etc.). The purpose of ROI inflation is to reduce/mitigate those kinds of effects-- things that might effect the edges of apotential target ROI and conspire to keep it away from the FA-WM mask.
Therefore, only a small amount of inflation should be necessary-- often just 1 voxel, but perhaps two depending on resolution, I guess. If one is having to inflate a lot to get an ROI to the WM, then probably it isn't a very good/useful target ROI (perhaps is noise-caused).
As part of this purpose, inflation should be done in each subject's DTI space after any warping has been done, so one can use the subject's FA volume with a threshold.
Whether you choose to inflate using -neigh_face_only (default), -neigh_face_edge or -neigh_upto_vert, should not matter very much-- there are different definitions out there about what a neighbor of a voxel is (e.g., as applied to clustering), and so one can use any of these, reasonably, as long as one is consistent. For example, if one performs clustering based on one type of neighborhood, then keep using that the rest of the way.

+ To select out your components: well, that is up to you. Probably several (say, about 10-15?) ICs might correspond to standard/recognizable FMRI networks, with other components likely representing noise/motion/mindwandering about breakfast cereal. How a given IC is categorized is up to the user. (One tool that might help one "recognize" components related to another "standard" map of them might be using AFNI's 3dMatch.)
You can run 3dROIMaker on the 4D data set of all 30 ICs, and then an output of a new 4D data set of 30 thresholded/ROI-ized maps. You can select which ICs are useful/meaningful to you from either file. You can use AFNI brick selector notation to grab those out from the dset, like: "FILE[0..3,5,6,9..11,14,18]", etc.

+ Note that when you run tracking, you can have a 4D dset of N networks that you selected-- you can put that into 3dTrackID, so that it can track all of them simultaneously, for efficiency's sake.

Happy to clarify/discuss/brainstorm on these or any other related ideas.

--pt