Introduce or not introduce SSIS to an ETL project Given is an ETL process that works fine using traditional SQL. 

The process is well optimized making use of ALTER TABLE permissions and performing partition switching, index creation, partition truncation and statistics updates.

Furhtermore a Scheduler is available that is up to the job.

What benefits would be gained from introducing SSIS to the project? Also would I get rid of needing ALTER TABLE permissions because SSIS interfaces at a lower layer to the database?

If additionally given that the project is small involving only one really large fact table and creating a data warehouse accessed only via SQL (no Analysis Services), does this affect the answer to the question?
The main strengths of SSIS as I see it are 1) the ability to do things across servers which aren't otherwise linked (eg via linked servers) and 2) the ability to do things in parallel (eg multiple Execute SQL tasks operating concurrently).

If you are using traditional SQL then you probably don't need 1), but you might need 2).  Your ETL must be running in serial, all one after the other.  If you look across your whole ETL process, are there any tasks that could run in parallel thus potentially saving you time?

SSIS also has several other abilities, eg the Script Component and Script Task allow you access to sophisticated .net scripting without having to use CLR in your SQL Server.  The Fuzzy Grouping Task allows you to group similar terms for comparison, way better than Soundex!  There are also third-party add-ins such as CozyRoc which has a vastly improved Excel connector and a partitioning task.

Regarding the permissions, SSIS jobs running under SQL Agent normally run under the context of the SQL Agent account, although you can change this using proxies.

Regarding the scale of your project, using SSIS would give you the ability to scale out in the future, eg if you suddenly have to process 10 facts instead of 1, you could do this in parallel whereas your current process would have to do them one after the other, in potentially the same time.  Maybe your scheduler handles some parallelism but I can't imagine it would have the level of control (eg conditional flow, redirect error output) that SSIS gives you.

HTH