I would be inclined to agree with the developers that using a NOT NULL constraint on the column's type may deliver (but there's no guarantee that it will deliver) better performance than a check constraint.  With the coumn declared NOT NULL, the query optimiser knows that it can't be null; with a check constraint, it doesn't know anything other than that there's a check constraint.  Having the optimser know the extra information may result in it delivering a better execution plan for some queries - it certainly won't cause it to deliver a worse plan; but the amount of improvement can't be known except by suck it and see, and it may be zero because perhaps none of your queries enable the optimiser to take advantage of the extra information.
But as a general principle, if a column is known not to be nullable it should be declared as not nullable because doing that may be useful.  A check constraint is not the right way to do this.

Changing the definition of a column to NOT NULL will not cause any size increase if there are currently no NULL values in the column.   If there are NULL values, the change would require all the NULL values to be changed to the default value  if there is a declared default for the column, and the change will fail if there are some NULLs and no default is specified (or the default is NULL).  If some rows have that column changed from NULL to a non-ull default, that may cause a size change.