The answer is, of course, "It Depends."
The question is how much SQL capacity is being used by existing applications against the existing SQL server. If the SQL server is very under used or if the SharePoint instance will only require minimal SQL resources, then you'll be fine.
Usually, SQL servers that support SharePoint are dedicated to that function to ensure consistant performance and to prevent application A from killing your sharepoint infrastructure. Sharepoint performance is heavily dependant on SQL performance so any bottleneck on SQL (CPU, IOPS, RAM) with negatively affect your Sharepoint performance. The other thing that usually drives people to dedicated SQL servers is that Sharepoint installs tend to grow quickly and beyond original expectations. Once people start using Sharepoint, it's not unusual to find the adoption ramp to be very steep and the capacity of the Sharepoint farm can get used up quickly once the system goes viral within the organization.
One other note is the implications of RBS. When deploying RBS, you can significantly reduce the impact of Sharepoint on your SQL server. If you're deploying a medium or small sized Sharepoint infrastructure and you have a very large SQL server, adding RBS may tip the scales and allow you to share that SQL server with other applications.
Lastly, SQL server has the concept of "Named Instances." This means you can have more than one logical instance on a single physical installation of SQL. You will definately want to run Sharepoint on it's own instance if you do decide to share the SQL server with other applications.
Alex
