My opinion - I would install the R/Python stuff in SQL if you need it to store processed data in SQL OR you need it to process data that will be passed back to an application OR if you are needing a centralized location for an R script to be used by multiple people. Kind of like SSRS or SSIS; if you don't NEED it on that instance of SQL, I wouldn't install it.
My reason for this - it uses resources on the server. R and Python I am pretty sure operate outside of SQL Server resources (memory and CPU). So if someone tosses in a high memory load to R or Python, that is going to eat up resources on my server.
Also, I would be asking them "why?". What is their business case for installing it on the SQL side? Sure it is possible, but they have indicated that there are no performance issues running it on their laptop, and it is for a single user.
Now, eliminating the need to pull data from the database to their laptop is a good reason to put it on the SQL side, but it will mean that more resources are used on the database side. It will have an impact. It might not be a large impact, but in my opinion, making a change to a server for a single user seems like overkill.
This is just my opinion. My thoughts on SQL Server is that it is where my data resides. SSIS and SSRS should reside on a different system than SQL Server (so as not to eat up resources, but comes at additional licensing costs so we currently don't have it set up that way) and same thing with R/Python. I want the database to be as fast as it possibly can be without the overhead of extra tools; especially tools that are going to be used by only 1 user.
I would also get them to add to the business case how much time they will save by having R on the SQL side. Lets say they are processing 1,000 rows of data in R that are 1 KB each for a total of 1 MB of data. If they are on a wired network connection on a LAN (ie no internet inbetween), they are looking at roughly 1 second to pull that data from the SQL side. Is that really worth the time and effort to install and maintain R/Python in SQL?
The above is just my opinion mind you. It may be that once it is there, more people will use it. OR it may be you spend the time to install it and the end user doesn't like the UI (SSMS/sqlcmd) needed for doing Python/R in SQL and will go back to how they did it before on their laptop...
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.