Storing daily yield curve data in SQL table
Your second choice (long) is preferable for the reasons you outline, provided you use the right keys and constraints.
Something like this is probably in the right direction:
CREATE TABLE Currency
(
  CurrencyCd    CHAR(3)      NOT NULL  /* This is the ISO currency code */
 ,CurrencyDesc  VARCHAR(50)  NOT NULL
 ,CONSTRAINT PK_Currency PRIMARY KEY (CurrencyCd)
 ,CONSTRAINT AK_Currency UNIQUE (CurrencyDesc)
 ,CONSTRAINT CK_CurrencyCd_Length CHECK (LEN(CurrencyCd) = 3)
)
GO

/* This is solely to prevent invalid values being added */
CREATE TABLE MaturityAge
(
  MaturityAgeYr  TINYINT  NOT NULL
 ,CONSTRAINT PK_Maturity PRIMARY KEY (MaturityAgeYr)
)
GO

CREATE TABLE CurrencyYield
(
  CurrencyCd     CHAR(3)       NOT NULL
 ,MaturityAgeYr  TINYINT       NOT NULL  /* Possibly consider using months if finer detail possible */
 ,AsOfDt         DATE          NOT NULL
 ,Yield          DECIMAL(9,1)  NOT NULL /* Can increase decimal precision if necessary */
 ,CONSTRAINT FK_CurrencyYield_Of_Currency FOREIGN KEY (CurrencyCd) REFERENCES Currency (CurrencyCd)
 ,CONSTRAINT FK_CurrencyYield_At_Maturity FOREIGN KEY (MaturityAgeYr) REFERENCES MaturityAge (MaturityAgeYr)
 ,CONSTRAINT PK_CurrencyYield PRIMARY KEY (CurrencyCd, AsOfDt, MaturityAgeYr)
)
GO

Here the choice of the composite clustered index form by the primary key (CurrencyCd, AsOfDt, MaturityAgeYr) ensures the data will be (more or less) stored sorted according to those columns.  That means any queries of the type WHERE CurrencyCd = 'EUR' will only read the relevant pages.
This choice of clustered index + storing the data in a &quot;long&quot; format will make &quot;widening&quot; the data trivial - so if you need to view the data as you provide in the first example, it's a simple PIVOT.
Other considerations:

If the volume of data is very large, but most of the values do not change, you can explore only storing changed values.  It takes a little more code to retrieve the data for a given date, but you can create date tables/views to simplify that.  If this is the case, let me know in the comments and I'll expand my answer.
Over time the table will fragment (a large number of records will not be co-located according to the clustered index), so the clustered index will need to be rebuilt occasionally.  There are a number of readily available tools/scripts to make this relatively simple.