What sort of application are you working on? Since you've had a database/T-SQL developer on your team previously, I assume that it's reasonably database-centric, but the answer to how the database is actually used by your application has an impact on whether a separate database developer is needed or helpful.
My initial reaction was "you want a T-SQL developer with database development experience on your team", but if the database is little more than a data store (little or no logic in the database layer), then perhaps you could make do without. Same if the database design is simple (meaning that to extract something useful you don't need umpteen million joins across dozens of tables), or if performance and scalability aren't great concerns in your case.
An obvious drawback of a separate database developer is the short-term cost of another developer who won't be contributing directly to the user-visible portions of the software.
Assuming that the application you are working on is reasonably database-centric, once the initial ramp-up period is taken care of, having a developer who can focus on the database aspects of the application can help quite a bit. You get someone who knows the ins and outs of set-based programming, can focus on what amount of data normalization in storage is useful in your particular case, and can hopefully help come up with or further the design of the database to provide good performance now and in the future.
Having an application developer also do database development doesn't necessarily have to be a bad thing, but there is an obvious risk that the developer in question will focus more on the needs on the application side than on what makes a good, scalable database design and then figure out how to expose that to the application layer in a way that provides the application with the data that it needs. This can lead to short-term results and long-term pain when the underlying design turns out to not be scalable. Of course it doesn't have to happen that way, but it's a risk well worth being aware of.
As for communications overhead (and particularly that causing delays), it doesn't have to happen that way. If the other developers on the team know a bit of T-SQL (it's not that hard picking up the basics like how to do selects, updates, joins, etc.), then they can certainly do prototyping in the database layer just to get the data that they need. Before the code goes to production (whatever that means in your environment), the database developer can either sign off on it saying that it's a good enough design, or take the input parameters, desired result and output result set design, and figure out a better way to perform the actual queries.