DataSource-kontrollerna är på sätt och vis en vettig idé. Ett flexibelt adapterlager mellan datakontroller och datakällor kan definitivt vara användbart. Dock finns ett antal problem.
* De riskerar att flytta in alldeles för mycket affärslogik i presentationslagret. I synnerhet SqlDataSource är en riktigt fuling när det gäller detta. SQL-satser i ASPX-filerna....hallå...
* De är inte särskilt väl implementerade. ObjectDataSource är en potentiellt trevlig kontroll, men den kan vara svår att passa in i en i övrigt väl uppbyggd arkitektur, pga av dess sätt att få tag på instanser och anropa metoder.
* De har en alldeles för framskjuten plats i ASP.NET 2.0, och den platsen har de fått på bekostnad av vettiga interface/metoder för "mer traditionella" databindningsmetoder
* Microsoft fortsätter att föra fram dem som Best Practice (inte överallt) medan resten av webbvärlden går emot mer modellstyrda ramverk.
Jag hade antagligen inte varit så kritisk om DataSource-kontrollerna var tredjepartsprodukter eller något man fick ladda ner extra från MS, men som det är nu kan jag inte riktigt förmå mig att gilla dem.
Dock! Viktigt! Om ett verktyg - oavsett om det är SqlDataSource eller något annat - gör dig effektivare som utvecklare, utan att du längre fram behöver kliva in i den funktionalitetsvägg som denna typ av hjälpmedel kan bli, så är det inte alls fel att använda dem.
Beträffande dina övriga frågor:
Det finns inget som hindrar att du skapar egna kontroller som kan bindas mot DataSource-kontroller.
http://msdn2.microsoft.com/en-us/library/ms366539.aspx
...och hur beroende du blir av Javascript etc. är helt upp till dig. DataSource-arkitekturen är helt serverbaserad och bryr sig inte om vad som händer på klienten.