Teradata : Disadvantage of Collect stats I want to know any disadvantage can occur by doing collect stats on a column that is being widely used in join condition across so many procedures ? (Eg. the column is accessed 300+ times access in 60 days)

While searching in google, i came to know the only issue that can cause performance degradation is out of date Stats. 
In this case, this is not going to happen as whenever data of table changes, we are going to run collect stats.

Any other disadvantage is there because of adding collect stats other than space consumption ?
The space consumption for statistics on Teradata is not significant enough to qualify as a disadvantage. For example, the statistics for a single column is retained in a 16KB VARBYTE column on DBC.TVFields

The rule of thumb has always been 10% change in the data which you have statistics collected or if they are stale. Unfortunately, stale has never really been clearly defined. Teradata 14.10 will introduce a more automated mechanism for maintaining statistics to help reduce the cost (CPU and IO) associated with the collecting stats using a homegrown maintenance schedule. This enhancement will be supported through Viewpoint. 

Teradata 14 also introduced some changes with statistics that have to be taken into consideration from previous releases. Carrie Ballinger has done a good job of capturing these changes in her articles on the Teradata Developer Exchange found here and here.

Your stats maintenance schedule will be driven by the size of your environment, your ETL schedule, and manner in which your ETL maintains the target tables. We have multiple streams that maintain the same set of large target tables. As such we have moved the stats maintenance for these target tables to an external process instead of within each ETL stream.