What made this issue particualy difficult to diagnose is that this wasn't reproducible under Default Web Site. When I placed the same application under C:\inetpub\wwwroot\subfoldeer\phpapplication under DefaultAppPool identity.
It was very easy for me to simply add Full Control to C:\inetpub\wwwroot\subfolder\phpapplication\data for DefaultAppPool and it simply worked.
After reading http://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-acls; with fcgi.impersonate turned on in php.ini; it will automatically impersonate the authenticated user. Viola, turning this feature off, the PHP process assumed the AppPoolIdentity and work as expected.
Which explain why I wasn't getting file access failures for KanboardPool. However it doesn't explain while fcgi.impersonate that was turned on under Default Web Site initially wasn't reproducing the same behavior.