If you want to increase performance reduce flexibility ... your best performing approach to this is to built a physical database object that has the data pre-aggregated and pre-calculated.

^ especially if you have large row-sets;

Having implemented OBIA over and over and been given these kinds of requirements ... my default way of getting performance is via the physical structure - yes, it's inflexible (a change in requirements is a restart); but it performs.  Ask your client what is more important performance or flexibility; outline the trade off.  If you know 3 mins is unacceptable - I'm thinking they want performance over flexibility.  But safer to have this discussion -- they have to support it after you are gone too!  Also have them consider the future - how fast is the row-count going to grow?  Might work now to be flexible and do it logically -- 18 months from now it doesn't.

Usually a restart isn't all that bad (cost in terms of labor) as you are typically using finished fact/dimension tables -- just changing the presentation 'layer' of the EDW.

YTD is

SELECT SUM(measure)

FROM table

WHERE date between trunc(sysdate,'YEAR') and trunc(sysdate)-1

SELECT trunc('06-JUN-2017','YEAR')  FROM DUAL;  <-- returns '01-JAN-2017'

MTD would be:

SELECT SUM(measure)

FROM table

WHERE date between trunc(sysdate,'MM') and trunc(sysdate)-1

SELECT trunc('06-JUN-2017','MM')  FROM DUAL;  <-- returns '01-JUN-2017'

as a bonus, LY YTD is

SELECT SUM(measure)

FROM table

WHERE date between add_months(trunc(sysdate,'YEAR'),-12) and add_months(trunc(sysdate)-1,-12)

Absolutely, the cube provides the best case -- if available.  Most of the clients I have been at they didn't have ESSBASE as part of the mix. 

Currently working on a Microsoft BI stack project (shhhh!) for a new EDW and have made great use of cubes for these types of cases!