You can achieve both, in and outside of sharepoint.

you can surface data, forms and some workdesk views on sharepoint directly, and you can surface data, forms and views in the workdesk as well.

it really depends on your company. I find it easier to not confuse users and send them to multiple locations, if you are mainly a sharepoint shop, I'd say go with sharepoint.

Think about the scope of  your applications and the need for SCALE. using Sharepoint Intergration you always will carry on the constraint of depend on the limit of records and the Sharepoint API.

If you think the application/forms/workflows will require scale up to a larger number, you might be much better off to work stand alone with the power of SQL and let K2 handle the overhead. we found only some case connecting with Oracle/SAP when 1 million records kind of have hard time to be handled by K2 other than that... if the application will have more than 20,000 records or the default 5,000 that is the lock limit for a list/library in Sharepoint perhaps something within the SQL lines for 100,000 records will be easy to manage.

Agree both solutions will work fine, but if you would require to scale later on, and don't like to have any dependencies attached to Sharepoint, which will allow you to upgrade to Sharepoint 2016 in the near future. I would choose stand alone with SQL. you can always use the same Sharepoint SQL Instance to allocate your K2 Data databases, much better than use the default smartbox. I think is much cleaner.

Good luck and happy 2017  !!!

Dino